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A NOTE ABOUT BAR CODES 


INTRODUCTION 


To those personal computer enthusiasts (such as myself) who have more enthusiasm than 
paticnce, go right on to Pass 1. You will not miss anything vital. 

Most computer operating system manuals that | have encountered have a common fault: 
they are written as reference manuals, never as teaching manuals. Each chapter gocs into great 
detail about a subject with the assumption that the reader is familiar with all of the other chap- 
ters, both preceding and following. As a result, the manual must be read several times before 
the fun part (hands on time) begins. 

This book is an attempt to remedy this problem. K2FDOS is described in a series of passes. 
The first pass gets the reader up and running on a computer system in a very few minutes. 
The reader can do useful and enjoyable computing with the 5% of K2FDOS capabilities avail- 
able in Pass 1. Successive passes go into greater detail on the structure, operation, and capacities 
of K2FDOS, from the most basic file naming conventions to the most intricate data base 
manipulation techniques. The reader can stop with any pass at any level of comprchension of 
the operating system and make use of the computer at that level. Indeed, there is more detail 
included in the book than most data base programmers will require, but the information is 
available specifically for the inveterate software hacker who wants to try every trick in the 
book. 

To provide the greatest possible software compatability, this book includes assembly 
language source code listings, object code in hexadecimal format, and machine readable assem- 
bled computer code in the form of optical (PAPERBYTE ® ) bar codes. Those who require 
source code or object code on paper tape are referred to Appendix O. 

As an indication of the effectiveness of FDOS, this entire book was written under FDOS and 
is stored on two floppy disks. | estimate that FDOS reduced the effort of writing and rewriting 
this book by at least two-thirds. 

All assembly listings in this book are assembled by an Intel 8080 assembler. Care has been 
taken wherever possible to avoid any unusual assembler features (such as macros) and the listed 
code should be intelligible to anyone who is familiar with almost any 8080 based machine 
language assembler. When numbers appear in the text or the listings, these numbers will always 
be in decimal unless followed by an H (e.g., ODOOOH) indicating hexadecimal. 

In the interests of personal computing, the author waives copyright restrictions on the non- 
commercial use and reproduction of this software. Purchase of the book includes a single user 
software license for the enclosed programs. 
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PASS 1: Getting K2FDOS Going 


If you are using this book as a manual for a system that 
is up and running and you are in a hurry, skip to Running a 
Program from the Disk and Using PIP later in this pass. 
If you are not in a hurry, start at Storing a Program on the 
Disk. If the system is not up yet, read Bringing the System 
Up. If the system is as yet nonexistent, start here. 


What You Need 


To be able to play games or store programs by the end 
of this chapter, you must have certain basic equipment. 
You need an 8080 based microcomputer system, a floppy 
disk drive and interface, and a floppy disk containing a 
copy of FDOS which has been customized to run on your 
computer. If your system is not yet fully assembled, then 
you will have to refer to Appendices G and H on the proper 
procedure for customizing the software to your system. 
Because this procedure requires rather specialized knowl- 
edge and takes a fair amount of effort,. it really has no 
place in Pass 1, and we will not refer to it here. It is as- 
sumed, now, that you are working with a correctly set up 
FDOS system, and you wish to use it with as little effort 
as possible. Read on. 


Bringing the System Up 


After making sure that all appropriate power is on to the 
computer, disks, and console device (such as a Teletype or 
video monitor), load a disk containing a copy of FDOS 
into the disk drive, and jump to the FDOS bootstrap 
address. This address will usually be CFOOH, or 317 000 
split octal. The bootstrap address may vary from machine 
to machine, and if this book is associated with a special ver- 
sion, the bootstrap address should be written here: 


Bootstrap Address 


In the case of an Imsai or MITS computer, loading the 
bootstrap address in the address switches and then switch- 


ing EXAMINE and RUN will cause the computer to jump 
to the bootstrap address. In systems with a “software 
front panel,” performing a JUMP, GOTO, or TRANSFER 
(depending on your computer system) to the bootstrap 
address will perform this function. 

Assuming that all has gone properly to this point, the 
following will occur: 


1) The disk drive will try to bootstrap FDOS. This is 
characterized by the head loading (and the disk rotation 
motor starting on the miniature floppy drive), and the 
head seeking in and out to track zero. 

2) FDOS will signal proper loading by typing out onto the 
system console the following message: 


K2 FDOS VERSION X.X (C) FEB 1977 K. WELLES 
DATE? 


3) You now respond by entering the current date as a one 
or two digit day of month, dash, the first three letters 
of the current month, dash, the last two digits of the 
current year, carriage return. Two examples are: 


4-JUL-76 <cr> 
25-DEC-77<cr> 


4) The computer responds with a dash (—) prompt indi- 
cating that it awaits your next command with eager 


anticipation. 


You have now successfully loaded FDOS into the system. 


Storing a Program on the Disk 


Before you can store a program on the disk, there are 
a few things you have to know or do. These are: 


1) A “good” disk (i.e., properly formatted, not write 
protected, and not completely filled) must be loaded 
into the disk drive. If more than one disk drive is avail- 


able, load it into the drive that you used to load FDOS 
with (drive 0). FDOS numbers its drives 0 and 1. 

2) FDOS must be present in memory, as loaded in the 
previous section. 

3) The program to be stored must be resident in memory, 
in the exact form in which it would be run. 

4) You must know the memory locations (in hexadecimal) 
which bound the program to be stored. 

5) You must know the starting address (in hexadecimal) 
of the program. 

6) You must choose a name for the program to be stored 
under. Any name with from one to six letters (A-Z) or 
numbers (0-9) may be used. Also, try to pick a pro- 
gram name that is different from any of the programs 
that are already on the disk. The file name does not 
have to begin with a letter. 


Let’s assume that all of these conditions are satisfied, 
and that we are storing MITS 3.2 BASIC in this example. 
BASIC occupies memory from about 0 to 1A00 (hexa- 
decimal), We will also assume that we want to store a 
user subroutine which resides between hexadecimal loca- 
tions 1F00 and 1FFF as part of the file named BASIC. 
The title of the stored program will be BASIC, and the 
starting address for execution (the transfer address) for 
this BASIC happens to be 0. BASIC and FDOS are in 
memory, a good disk is loaded in the drive, and we want 
to store BASIC for later use. We use the following steps 
(throughout this book <cr> indicates a user entered 
carriage return): 


—SAVE BASIC<cr> 
*LIMITS 0,1A00<cr> 
*LIMITS 1F00,1FFF<cr> 
*GO 0<cr> 


Example 1.1: The series of commands used to store the 
program “BASIC” onto disk. 


—SAVE BASIC<cr> 
*LIMITS 1F00,1FFF<cr> 
*LIMITS 1000,1A00<cr> 
*LIMITS 0,FFF<cr> 
*GO 0<cr> 


Example 1.2: Another series of instructions that could be 
used to store the program called “BASIC” onto disk. 


—SAVE BASIC<cr> 
*LIMITS 0,1FFF<cr> 
*GO 0<cr> 


Example 1.3: These instructions could be used to store the 


Program called “BASIC” if the location of the program in 
memory is not Rnown exactly, 


——— 


1) In response to the FDOS dash prompt, enter: 
—SAVE BASIC<cr> 


2) After successfully entering the name BASIC into the 
directory of this disk, FDOS prompts the user with an 
asterisk (*) for the limits of the program to be stored, 
and the user then enters (for this example): 


*LIMITS 0,1A00<cr> 


3) FDOS now saves the data in memory locations 0 
through and including 1AQOH onto the disk in a file 
named BASIC. When this much data has been properly 
stored on disk, FDOS requests either additional limits 
of other memory areas to be saved, or the transfer ad- 
dress of the BASIC program to signify that no more 
memory is to be saved. Since we wish to also save 
the user subroutine, we enter: 


*LIMITS 1F00, 1FFF<cr> 


Make sure that there is a space between the word LIMITS 
and the two numbers. 

4) FDOS repeats step 3 and again prompts with an asterisk. 
To indicate no further data is to be stored, enter the 
transfer address of the BASIC program: 


*GO O<cr> 


which indicates that when BASIC is brought in from the 
disk, FDOS will branch to OOOOH to start the program 
BASIC executing. 

5) FDOS now puts this final information out onto the disk 
and returns to its initial prompt of a dash (—), indicating 
that it is ready for the next command. 


In summary, storage of BASIC on the disk consisted of 
the series of commands shown in example 1.1. 

We could just as easily have used the series of commands 
shown in example 1.2. The same information would have 
been stored, and the two programs would both run in the 
same fashion. 

Had we not been certain of exactly where the program 
was located in memory, then the command series given in 
example 1.3 could have been used. The extra data from 
1AQ0H to 1FOOH would have been stored on the disk, but 
we would be certain of getting the entire program. This is 
sometimes more important than being stingy with the 
disk space. 


Running a Program from the Disk 


If the series of commands required to save BASIC onto 
the disk seemed complicated or confusing, take heart. To 
run that program entails much less work. The things to be 
done or known in order to runa program are: 


1) A disk containing the desired program must be loaded 
in the drive (in drive 0 on a multiple drive system). 

2) You must be in FDOS, with the dash (—) prompt 
awaiting your command. 

3) You must know the name of your program, 


Assuming these conditions are satisfied, you now enter 
(following the previous example): 


—RUN BASIC 


FDOS will find BASIC, load it into the proper memory loca- 
tions, and transfer the computer to the starting address of 
BASIC, whereupon the console will type out something like: 


BASIC VERSION 3.2 
MEMORY SIZE? 


If at some time you wish to leave BASIC and return to 
FDOS to run or save another program, you must go to the 
FDOS starting address. This start address is normally 
DOOOH unless you have a special system with the starting 
address entered here: 


Starting Address 


Re-entry into FDOS causes only the dash prompt. The 
date is requested only during the system bootstrap. 


File Handling 


What you have learned at this point in the book will 
probably be sufficient for between one hour and one week 
of work on a computer system with FDOS. In that period 
of time, one of two things will occur: suddenly you can 
not remember the names of all of those marvelous programs 
that you stored on the disk(s), or the computer has been 
typing out error messages which, when looked up in Ap- 
pendix J, tell you that your disk or directory is full. 

Before you can make much further progress, you really 
need a way to find out what programs are on which disk(s), 
and a method of removing the programs from the disk in 
order to free up the space for other programs. 

What you really need is a file handling program. By 
now you may have deduced that when a program is stored 
on the disk, it is stored in a “file,” complete with a “file 
name.” We now need a program that can delete files, or 
list which files are present on any disk. There exists just 
such a program called PIP that does precisely this. 


Using PIP 


Since we assumed that the disk and system you are 
working on contains a customized copy of FDOS, it will 
be a logical assumption that this disk also contains a copy 
of PIP. PIP performs many functions, but for Pass 1 we 
will discuss only three: DIRECTORY, DELETE, and 


EXIT. To run PIP simply enter: 


—RUN PIP<cr> 


The computer will load PIP from the disk into memory 
and start execution by typing: 


8080 PIP VERSION X.X 


In order to determine what files are present on a disk, sim- 
ply request a disk directory by typing: 


*DIRECTORY<cr> 


to which the typical response might be what is shown 
in example 1.4. This directory tells you that there are only 
four files on the disk: SYSGEN, FORMAT, PIP, and 
BASIC. It gives you the dates on which these files were 
created (by a SAVE command), and the number of blocks 
that each file uses on the disk. Finally, the number of 
blocks remaining for you to use is shown. 


Deleting Files from the Disk 


Whenever too few blocks are left, or too many file 
names are present, you might wish to remove one or more 
old files you no longer need. If you receive an updated ver- 
sion of BASIC, for instance, you might wish to remove the 
old version from the disk before storing the new version, 
thereby allowing the new version to be named BASIC 


FILE NAME DATE LENGTH 
BASIC. 30—SEP—77 28 
FORMAT. 15—FEB—76 3 
PIP , 02—NOV—76 7 
SYSGEN . 10—MAR-—77 3 


1036 FREE BLOCKS 


Example 1.4: A typical response to the DIRECTORY 
command, 


*DIRECTORY<cr> 


FILE NAME DATE LENGTH 
FORMAT. 15—-FEB—76 3 
PIP »  02-NOV-76 7 
SYSGEN. 10-MAR-77 3 


1064 FREE BLOCKS 


Example 1.5: The same directory as shown in example 1.4 
after the program “BASIC” has been deleted. 


——————————————————————————————————o 


instead of, say, BASIC2 or NEWBAS. 

To remove a file from the disk (in this example BASIC), 
you must first be in PIP (see the preceding section). Then 
enter the following: 


*DELETE BASIC<cr> 
————— 
OOOO 


(bootstrap) 

K2FDOS VERSION X.X (C) FEB 1977 K. WELLES 
DATE? 12—NOV-—77 

—SAVE SAMPLE<cr> 

*LIMITS 100,220<cr> 

*GO 160<cr>. 

—RUN PIP<cr> 

8080 PIP VERSION X.X 

*DIRECTORY<cr> 


FILE NAME DATE LENGTH 
BASIC. 30—SEP—77 28 
FORMAT. 15—FEB—76 3 
PIP ; 02—NOV—76 7 
SAMPLE . 12—NOV—77 2 
SYSGEN . 10—MAR—77 3 


1034 FREE BLOCKS 


*DELETE SAMPLE <cr> 
SAMPLE DELETED 
*EXIT <cr> 

—RUN BASIC <cr> 

MITS BASIC VERSION 3.2 
MEMORY SIZE? 


Example 1.6: A summary of the commands discussed in 
Pass 7, 


This will cause BASIC to be deleted, and it will add 28 
blocks to the number of free blocks on the disk. PIP 


will type out: 


BASIC DELETED 


A directory listing after this command would then yield 
what is shown in example 1.5. 

Caution! Make sure that you really want to delete a 
program or file before you delete it. If you make a mistake, 
it is very difficult (or impossible) to ever get that file back. 
And deleting PIP is a sure road to trouble. 


Returning to FDOS from PIP 


When you are finished with PIP and wish to return to 
FDOS to run some other program, simply enter: 


*EXIT<er> 


and the computer will re-enter FDOS and signify that it is 
in FDOS by typing the dash prompt. 


Summary 


Example 1.6 summarizes what has been covered in 
Pass 1. 

This bare minimum is sufficient for all of your simplest 
requirements of program storage and retrieval. You do not 
need to ever go any further into this book if you are only 
using the FDOS system to hold the programs that you write 
or copy from others. 


PASS 2: More Detail on FDOS 


Pass 1 left several details unmentioned or unexplained in 
an effort to get the reader up and running on FDOS quickly 
and simply. Nothing incorrect was written, but several 
points were incomplete or missing altogether. Pass 2 will fill 
in many of these blanks and will also cover some different 
material. This chapter will complete the explanation of all 
of the available FDOS commands and describe fully the 
conventions that FDOS uses to name files or programs. 
Pass 2 will also describe more of the various jobs that FDOS 
can do for you. Finally, Pass 2 will begin to describe 
various parts of FDOS which are available to the program- 
mer (as opposed to the operator or casual user). When this 
chapter is fully assimilated, you will understand much 
more about PIP and FDOS, and the philosophy inherent 
in this operating system. For FDOS users who do not know 
machine or assembly language, this is the last chapter that 
will be of any use. For the programmers and operating 
systems enthusiasts, however, this is where the real fun 
begins. 


More FDOS Commands 


A few readers might say “What? More FDOS com- 
mands?” upon starting to read this section. Some will say 
“That’s all?” after finishing it. In this section there is only 
a small addition to the SAVE command, and one new 
command introduced (JUMP). That concludes the entire 
repertoire of K2FDOS. And while large computer operating 
systems typically have more commands, and more sophis- 
ticated commands, they do not fit into 4 K bytes of memory 
(including buffers). 


The QUIT Command 


In Pass 1 the SAVE command was described as a way to 
store a program which would be run at some later time. 
However there may be times when the data in memory that 
should be saved is not a runnable program. Alternatively, 
there may be some programs that you wish to store, but 


you do not want this program to start running as soon as 
it is brought into memory from the disk by the FDOS RUN 
command. For instance, you may wish to enter new data 
into the program just read in before running it, or perhaps 
you wish to begin execution of the program at different 
addresses depending on which part of the program you 
need at any one time. In these instances, and in several 
other possible situations, you do not want to use the 
GO command to specify a transfer address for the SAVED 
program. 

In the above situation, you will use a QUIT command. 
QUIT is used in place of the GO command, and without a 
transfer address. When you RUN a program which was 
SAVED with a QUIT command at the end, the program 
is read into memory. After the program is read, FDOS does 
not try to run the program, but rather goes back to the 
point where it types out a dash prompt (—) and awaits 
further instructions from the user. So, a QUIT command 
finishes the SAVE operation. An example of the proper 
use of the QUIT command using the BASIC program from 
Pass 1 is shown in example 2.1. 

Now if we try to run BASICQ, we get the following: 


—RUN BASICQ<cr> 


FDOS has read the BASICQ file into memory, but 
instead of immediately executing it, control is returned to 
FDOS. At this point, FDOS can accept another command. 


2 ——————————d 
oe ———————————— 


—SAVE BASICQ<cr> 
*LIMITS 0,1A00<cr> 
*LIMITS 1F00,1FFF<cr> 
*QUIT<cr> 


Example 2.1: An example of the proper use of the QUIT 
command. 


7 
——————————————————~“—N —\YS—S—*—O 


The JUMP Command 


The final FDOS command is JUMP, which simply causes 
the computer to jump to a specified address. The transfer 
address is specified as any hexadecimal number from 0000 
to FFFF inclusive. If you know that some program is in 
memory and you want to leave FDOS and go to the pro- 
gram at location 10H, for instance, the following command 
will accomplish that: 


—JUMP 10<cr> 


An example of a use of this command would be the 
program BASICQ which was SAVED in example 2.1 
with a QUIT at the end instead of a GO. To run BASICQ, 
you would enter the commands shown in example 2.2. 
Another example of the JUMP command would be in 
the event that you had EXITed from PIP back to FDOS, 
and then wished to return to PIP without reading it from 
the disk again. In this case, knowing that PIP starts at 10H, 
you could perform the instructions shown in example 2.3. 


—RUN BASICQ<cr> 
—JUMP O<cr> 


BASIC VERSION 3.2 
MEMORY SIZE? 


Example 2.2: An example of the proper use of the JUMP 
command. 


—RUN PIP<cr> 

8080 PIP VERSION X.X 
*EXIT<cr> 

—JUMP 10<cr> 

8080 PIP VERSION X.X 
* 


Example 2,3: Re-entering PIP using the JUMP command, 


—S BASIC<cr> 

*L 1F00,1FFFH<cr> 
*L 1000,1A00<cr> 
*L O,FFFF<cr> 

*G 0<cr> 


Example 2.4: One letter abbreviations can be used for 
commands, Except where noted, FDOS ignores all but the 
first character of each command as it is entered. 


A 

3D 
BEETLE 
Q9/? 


Example 2.5: Some of the various legal base names, 


e65=—=NalkeNNwaqIe——O 


If at some time you wish to bootstrap in another version — 
(or reboot the current version) of FDOS the command: 


—JUMP CFOO<cr> 
K2 FDOS VERSION X.X (C) FEB 1977 K. WELLES 
DATE? 


will perform the bootstrap. Obviously, for this to work 
correctly the bootstrap read-only memory must reside at 
CFOOH in memory. 

NOTE: Make sure that you know where you are jumping 
to. Jumping to an address with unknown contents can 
destroy whatever data or programs you have in memory, 
and may destroy FDOS. 

This completes the description of all FDOS commands 
(RUN, JUMP, and SAVE) which are available to users 
through the consoles of their computers. 


Abbreviating the FDOS Commands 


Up to this point, all of the examples and descriptions of 
FDOS commands have fully spelled out the FDOS key- 
words: RUN, JUMP, SAVE, LIMITS, GO, and QUIT. You 
may have guessed by now that the entire keyword is not 
required. Actually, FDOS looks only at the first letter of 
the command, and then ignores all following letters until a 
space or carriage return is found. If further data is required 
after the keyword (a file name after RUN or SAVE, hexa- 
decimal number(s) after JUMP, LIMITS, and GO), then 
this data is expected to follow immediately after the first 
space following the keyword. 

Using the one letter abbreviations, example 1.2 can be 
reduced to what is shown in example 2.4. 

Note that since all but the first letter of a command is 
ignored, SAVE could be entered as STORE or STICKON- 
THEDISK and RUN could be entered as READ or 
RETRIEVE, if these words are preferable or would make 
the record of your efforts more understandable at some 
future time. 


Filename Specifications 


Pass 1 taught you that a one to six letter (or number) 
string was a file name. This is the truth, but again not the 
whole truth. A file name consists of three parts, one manda- 
tory and two optional. These parts are the base name, the 
extension, and the device number. 

The base name must be present in any file name and 
consists of from one to six characters. These characters 
can be any number or letter (upper or lowercase), or any 
other printing character which is not a period or a colon 
and which has an ASCII value greater than the ASCII 
value of a period (2EH). Examples of legal base names 
are given in example 2.5. 

The extension is an optional one, two, or three charac- 
ter string, using the same character set as the base name. 


If the extension name is present, it must be separated 
from the base name by a period. The conventional usage 
of the extension is to denote different types of files. For 
instance, if you have written an assembly language program 
called TRACE, the assembly might create an object code 
file and a program listing file on the disk. Editing the 
source program might cause a backup copy of the source 
program to also be stored on the disk. To keep these files 
separate without having to think up new base names for 
each one, they could be named as shown in examples 2.6 
or 2.7. 

Finally, the drive number or device number may follow 
the base name and extension (if the extension is not present, 
the drive number follows the base name). The drive number 
is a one digit number from 0 through 7, and is separated 
from the rest of the file name with a colon (:). This drive 
number need only be used if your computer has more than 
one disk drive or a dual-sided floppy disk system. If no 
drive number or colon is present, then disk drive 0 is 
assumed. If a disk drive number is present, then FDOS 
assumes that this file is to be found on the disk in that 
particular disk drive. Make sure that you do not specify 
drive 2 on a two drive system, as only drives 0 and 1 exist. 
Obviously the system cannot carry out any operation ona 
disk drive that does not exist. Some examples of valid file 
names are given in example 2.8. 


Buffered Command Strings 


FDOS contains an editing command string buffer, and 
all commands to FDOS are processed by this buffer. 
This simply means that any commands (RUN, SAVE, 
JUMP) that you type into FDOS pass through a special 
routine which allows you to correct mistakes or change 
your mind on any command, as long as you realize your 
mistake before you hit the carriage return key. Naturally, 
no command to FDOS is acted upon until after a carriage 
return is given by the user. During the entering of a com- 
mand there are three special keys for editing: Rubout, 
Control-R, and Control-X. 


ed 
———_—_—_—_—_—_—_—_—_——————— 


RUN BASC<rub>IC<cr> 
—RUN BASCCIC<cr> 
—RUN BASIC<cr> 


Rubout 


If you enter Rubout (sometimes labeled RUB, DEL, or 
DELETE on the keyboard) during the entry of a command, 
it causes the last character entered to be removed from the 
command. The deleted character is typed out onto your 
console to indicate what you removed with the Rubout. 
Multiple Rubouts will remove multiple characters from 
your command. Large numbers of Rubouts will remove 
your entire command without causing errors. Example 2.9 
has three lines showing first what is typed on the keyboard 
by the user, what is typed out onto the console by the 
computer, and finally how the computer sees the command 
after the carriage return. 


Control-R 


The Control-R (denoted “R) is a tool to clear up the 
jumble of characters made by using several Rubouts. 


TRACE The original source program 
TRACE.BAK The backup copy from the editor 
TRACE.BIN The assembled binary copy to run 
TRACE.LST The assembly listing 


Example 2.6: This example shows the valid use of exten- 
sion names for the base name TRACE. 


a.a 
Q39.43A 
DOLLAR.??? 
RINKY.DNK 
R2.D2 


Example 2.7: Other valid base names with extensions. 


BASIC on drive 0 
This is identical to the specification above. 


BASIC:0 
BASIC 


Vv 
TRACE.OLD:1 


A:2 
234567.890: 1 Legal, but confusing 


Example 2.8: Examples of valid file names. 
Typed in by user 


Typed out by the computer 
What the computer sees 


Similarly, with multiple Rubouts: 


—RUN TRACE:0<rub><rub>.BIN:1<rub>0<cr> 


—RUN TRACE:00:.BIN:110<cr> 
—RUN TRACE.BIN:0<cr> 


Typed in by the user 
Typed out by the computer 
What the computer sees 


Example 2.9: An example of how the Rubout key can be 


used to edit a line of input. 


——— ne 


Typing in a “R is accomplished by holding down the 
Control key and typing R. Typing a “R at any point in 
a command causes the console to type out a carriage 
return, line feed, then the command string with all of the 
Rubouts removed, just as the computer sees it. If the 
response to the “R shows that the computer sees the 
command the way you expected it to be seen, you can 
then finish entering the command. Example 2.10 shows 
the use of “R. 

“R can be typed any number of times, since typing 
it has no effect on the actual command string except to 
retype it as it exists at the time that the “R is entered. 


Control-X 


The Control-X (*X) is the “I give up, let me start from 
scratch” command. Typing in a ~X is accomplished by 
holding down the Control key while hitting X. This causes 
FDOS to type out a carriage return and line feed, and to 
erase the entire command string buffer; that is, it accepts 
a new command from the beginning. Note however that 
FDOS will not give a new prompt. The user is to assume 
that the prompt from the previous line (dash or asterisk) 
is present. An example of the use of “X is shown in 
example 2.11, where the user realized that he or she wanted 
to read PIP in, not to store it on the disk. The aborted 
SAVE command is completely ignored. 


More PIP Commands 


Pass 1 demonstrated that PIP is a handy program. PIP is 
not reallly part of the operating system, but is actually a 
fully independent program designed to be run by FDOS in 
the same way as any other program. The writeup of PIP is 
included in the FDOS book because PIP does many of the 
things that a large operating system is expected to do, but 
that cannot be done in FDOS because of size restrictions. 


PIP is not constrained to 4 K bytes, and as a result it can 
do many tasks that normally would not be included in even 
a large operating system. 

Pass 1 described DELETE, DIRECTORY, and EXIT, the 
three most basic and necessary commands to allow PIP and 
FDOS to be used at the simplest level. This section will 
cover six more commands: FREE, COPY, RENAME, LIST, 
READ, and PUNCH. It should be noted that with PIP, as 
with FDOS, Pass 1 did not tell the whole truth. Only the 
first three letters (not just one letter) of any command are 
needed by PIP. All characters after the third character and 
before the first space or colon are ignored by PIP. Any of 
the commands given in example 2.12 will cause PIP to 
type out a directory. 

All commands to PIP go through the FDOS editing 
command string buffer described previously in this chapter. 
Therefore, any corrections to or cancellations of commands 
may be done in the manner described previously. The 
editing buffer and the three letter command rules apply to 
all PIP commands: those shown in Pass 1, those immediately 
following, and those in later chapters. 


Directory 


The command DIRECTORY (or DIR) will cause the 
directory of the disk in drive 0 to be typed out onto the 
console device. In order to get the directory from the 
second disk drive (drive 1), the user types in: 


*DIRECTORY:1<cr> 
or 

*DIR:1<cr> 
Using this form of the DIRECTORY command, the user 
may get a directory from any drive on a multiple drive 


system, by simply entering the drive number (from 0 
through 7) after the colon. 


SS 770—=—~“—S—SOOOS.0—NeoOoeoeoeoeoeoeee—————— ee, 


SAVE COBIC<rub><rub><rub><rub>UBIL<rub>C.BIN<*R> 


—SAVE COBICCIBOUBILLC.BIN 
SAVE CUBIC.BIN 


The string of characters typed in by the user. 


Printed by the computer in response to “R. 
What computer sees, printed by computer in response to *R. 


Example 2.10: An example of the use of Control—R to 
cause the computer to retype an input line. 


—SAVE PI<*X> 
RUN PIP<cr> 


Example 2.11: The use of Control—X to delete an entire 
input line. 


*DIR<cr> 
*DIRECTORY<cr> 
*DIRECTMETOYOURLEADER<cr> 


Example 2,12: Valid commands that will cause PIP to print 
the disk directory. 


oS 


f FREE 

One feature of paramount interest to most users is “How 
much room do I have left on the disk?” Remember that 
the number of free blocks left on any disk is typed out 
(Pass 1) at the end of the DIRECTORY command. How- 
ever, the user is usually most interested in how much space 
is left when the disk is almost full. On almost full disks, 
there are usually many file names, and you may not want 
the computer to type out a full directory with 200 or more 
file names just to find out that there are 87 blocks left. 
Therefore, simply command PIP with FREE or FREE:x, 


where X is the number of the desired disk drive (see 
example 2.13). 


RENAME 


Frequently you will find the need to change the name of 
a file or program stored on the disk to some new name. A 
typical reason for this would be in the case where you have 
a copy of TREK that you know works well, and you have 
developed a new improved version that you want to try out 
for a while to assure yourself that it is bug free. Not want- 
ing to lose the old file, you could rename it to TREK.BAK 
before entering the new copy as TREK. This would be 
accomplished as follows: 


*RENAME TREK TO TREK.BAK<cr> 


There must be at least one space between the words 
RENAME, TREK, TO, and TREK.BAK. Renaming may 
be done on any disk drive, as shown in the following 
example: 


*REN TREK:2 TO TREK.BAK:2<cr> 
Note that the following is not legal: 
*RENAME TREK:1 TO TREK.BAK<cr> 


because the file must remain on the same disk (since 
there is no explicit device number qualifying TREK. 
BAK, device zero (0) is assumed). Transferring programs 
or files from one disk to another is the job of another PIP 
command, COPY. 


COPY 


The COPY command in PIP does exactly what the name 
implies. It copies one file (or program) into another. This 
allows you to make duplicates of any file or program that 
you wish. Particularly important when you have a multiple 
drive system, COPY allows you to copy programs and data 
files from one disk to any other disk. The standard format 
of this command is: 


*COPY NEWFIL FROM OLDFIL<cr> 


First enter the COPY command, a space, then the name 
of the new file (the file that is to be created; in this 


example, NEWFIL), next another space, the word FROM 
(or just the letter F), and finally the name of the old file 
(the file that is to be copied; in this example, OLDFIL). 
Make sure that this order is correct, since it is backwards 
from the rename command. The example above causes a 
new file to be created on disk 0 with the name NEWFIL, 
which will be an exact copy of OLDFIL. If OLDFIL 
was a program that could be run, then 


RUN OLDFIL<cr> 
and 


RUN NEWFIL<cr> 


will cause exactly the same program to run (but from 
different files). 

Files can be copied from one disk to another on a 
multiple disk system in the following manner: 


*COPY PIP:1 FROM PIP<cr> 


In this example, a copy of PIP from the disk in drive 0 
is put onto the disk in drive 1. This allows you to create 
multiple disks with all of your desired files on them. 

There is one final feature of COPY that should be 
explained. COPY also allows you to copy multiple files 
into one file. This feature is useful when you wish to 
copy several prewritten assembly language subroutines 
into one main program. This command could be written 
as: 


*COPY TOTAL FROM SUB1,SUB2:1,SUB3,MAIN<cr> 


If you examined the newly created file TOTAL after 
executing this command, you would find first the contents 
of the file SUB1 from disk 0, followed by the contents of 
file SUB2 on disk 1, then the contents of SUB3 from 
disk 0 and finally the contents of the file MAIN from 
disk 0. Note that none of the files SUB1, SUB2:1, SUB3, 
or MAIN are changed in any way. 

NOTE: If you copy multiple program files (disk files 
that were SAVED and that you can RUN) into a single file, 
and then try to RUN that file, only the first program will 
be brought in from the disk and executed. 


2 | 
SSS £00 0 0 OOO ee 


8080 PIP VERSION X.X 
*FREE<cr> 

87 FREE BLOCKS 
*FREE:1<cr> 
1032 FREE BLOCKS 
*FREE:0<cr> 

87 FREE BLOCKS 


* 


Example 2.13: Examples of the use of the FREE command 
under PIP. 


ees 


10 


Non-console Input/Output Devices 


FDOS provides special entry points for three extra input 
or output devices: a line printer (or any form of hard copy 
listing device); a paper tape reader; and a paper tape punch. 
Appendix G tells how to interface such devices to FDOS if 
you have them. The next three PIP commands make use of 
these devices. For purposes of continuity it is assumed that 
the FDOS system that you are working with has these 
devices interfaced to the computer in hardware, and to 
FDOS in software. 


LIST 


The LIST command allows you to copy any text file 
(such as the source code of a program to be assembled) 
onto your console or listing device. Examples of the format 
of the LIST command are given in examples 2.14 and 2.15. 

These examples will cause the file named TRACE.SRC 
on disk drive 0 to be listed on the console (example 2.14) 
or the line printer (example 2.15). The LIST command will 
expand all horizontal tabulation characters it finds (ASCII 
value = 09H) into one to eight spaces as required to bring 
the printer to the “tab stops” located in every eighth 
printing column. Note that, although the command “LIST 
TRACE.BIN<cr>” is perfectly legal, attempting to list a 
binary file (a program which can be RUN) will print a 
tremendous amount of “garbage”. If, during a listing, you 
wish to stop the listing and return to PIP, simply hold 
down the Control key and type C. Control-C will cause the 
listing to abort after the next character is printed. Typing 
any other character during a LISTing will cause the listing 
to halt until a second character is typed. 


PUNCH 

The command PUNCH allows you to punch the contents 
of any disk file out onto your punch device. A leader and 
trailer are placed before and after the contents of the file. 
The leader and trailer each consist of 60 null (binary zero) 
characters, which gives you six inches of blank tape at the 
_————————————— 


*LIST TRACE.SRC 


Example 2.14: An example showing how to list the disk file 
TRACE.SRC to the console device, 


*LIST:L TRACE.SRC 


Example 2.15: An example showing how to list the disk file 
TRACE.SRC to the line printer. 


ee ee ee 
==——ooooooeeeee 


start and end of a standard punched paper tape, to facilitate 
handling. If no special punch device is interfaced to FDOS, 
the file will be sent out to the console device. If your 
console device is an ASR Teletype, this allows you to use 
the attached paper tape punch as your punch device. 
Unlike LIST, PUNCH does not expand tabulation charac- 
ters. An example of the PUNCH command would be: 


*PUNCH TRACE.SRC<cr> 


which in this example will cause the source code of TRACE 
to be copied onto paper tape. This is a handy method for 
separate media backup and program interchange. 


READ 


Finally, PIP also has a counterpart to the PUNCH 
command, which allows a paper tape (or other medium) to 
be read into a disk file. To use the READ command, simply 
type READ followed by the name you wish this file to have. 
No file with this name may already be present on the disk, 
or an error will occur. An example of the READ command 
is: 


*READ PASS2<cer> 


This is an actual example of what was typed to copy a 
backup paper tape of the text of this book onto the disk 
for editing. PIP creates a file named PASS2 on the disk in 
drive 0, and then copies the paper tape into that file. When 
the paper tape reader finds the end of the paper tape, PIP 
closes the file called PASS2 and is then ready for the next 
PIP command. 


Summary 


After reading this chapter, you have learned essentially 
everything about FDOS and PIP you need to know if you 
do no programming in machine language. This chapter 
completes the specification of all FDOS commands (RUN, 
JUMP, and SAVE with LIMITS, GO, and QUIT) and their 
one or more letter abbreviations. The full specifications for 
the legal file naming conventions (FILNAM.EXT:1) were 
given. Instructions were given on the use of the three 
special editing keys (Rubout,~R, ~X) that allow correction 
of mistakes in both FDOS and PIP commands. Finally six 
more PIP commands (FREE, COPY, RENAME, LIST, 
READ, and PUNCH) were described. 

This section completes all of the documentation the 
novice and intermediate computer user needs to make full 
use of FDOS. The passes that follow go into increasing 
detail about the construction and operation of FDOS, how 
to make special use of various internal FDOS routines (not 


commands), and the various aspects of directory and file 
structures. 


PASS 3: Using FDOS Routines 


in Your Own Programs 


There are a series of 29 special FDOS routines known 
as User Accessible Routines (UARs). These routines are 
particularly useful to the users in allowing them to perform 
special functions under FDOS control. These functions 
include reading and writing files to the disks, searching 
for files, creating and deleting files, managing memory, 
performing input and output to the console, line printer, 
paper tape punch and reader. Pass 3 introduces the reader 
to some of these routines, what they do, how to call them 
and when to use them. It is not my intention to explain 
how they work in Pass 3. It will be easier and more logical 
to explain that after you know what the UARs do. This 
chapter describes the routines needed to communicate 
between your program and the FDOS console device, 
and also how to read and write a disk file from your pro- 
gram. 


User Accessible Routines 


FDOS has 29 different User Accessible Routines (UARs). 
To facilitate interfacing FDOS to other programs, each 
UAR has a fixed entry point which is always a specific 
distance (offset) from the beginning of FDOS. Table 3.1 
gives the offsets of the 17 routines to be described in 
this chapter. To call any one of the routines, you simply 
program a call to the address resulting from adding the 
offset of the desired routine to the starting address of 
FDOS. For example, if FDOS starts at DOOOH, as described 
in this book, then to call the MEMCHK routine, the user 
can program: 


CALL OD082H ;CALL MEMCHK ROUTINE 


or, alternatively, 


ODOO0H 
FDOS+82H 


FDOS EQU 

MEMCHK EQU 

CALL MEMCHK 
or simply 


CD 82 DO 


in machine language (hexadecimal notation). 


In addition to the UARs, there is also a set of six User 
Accessible Addresses (UAAs). These are addresses of 
various data structures used by FDOS that may be needed 
by the user for certain routines. Table 3.2 shows two of 
these UAAs, and the offset from the start of FDOS where 
the UAAs are stored. Note: The address formed by adding 
the UAA offset to the FDOS starting address is not the 
UAA, but it is the address of the first of two bytes whose 
contents are the User Accessible Address (least significant 
byte first). The following instructions: 


FDOS EQU ODOO0H 
REDFIL EQU FDOS+2AH 
LHLD- REDFIL 


will put the User Accessible Address REDFIL into registers 


ROUTINE OFFSET 


Ci 37H get console input character in A ~ 
Ri 3AH get one byte from reader in A 

co — 3DH put character in C out to console 
PO 40H put character in C out to punch 
LO 43H put character in C out to listing 
CSTs 46H return console status in A 
FDREAD 4FH read a character from disk toA 
FDWRT 52H send character in C to disk 
OPNIN 64H open an input file 


~ epen an output file 
close an output file 
get a file name from TXTIN 


LOKFIL 70H look for this file 
TXTYP 73H _ type text starting atM 
Thee 76H return buffered character in. C 


TXTIN 79H 
MEMCHK 82H 


input a buffered line from the console 
check how much RAM is in the machine 


Table 3.1: Offsets within FDOS of the beginning of the 
17 routines discussed in Pass 3. 


‘NAME 


OFFSET 
REDFIL 2AH system input buffer area address 
system output buffer area address 


WRTFIL = 2CH 


Table 3.2: Offsets within FDOS of the beginning of the 
REDFIL and WRTFIL User Accessible Addresses. 


11 


12 


H and L. The following instructions: 


LXI H,REDFIL ;THIS IS AN ERROR 


will not work, and is an error. 

All User Accessible Routines are called by calling the 
actual UAR location, and all User Accessible Addresses 
are loaded into registers H and L by an LHLD (load high 
and low direct) instruction. This holds true for the entire 
book unless otherwise noted. 


Non-Disk Input/Output 


The first six FDOS User Accessible Routines (UARs) 
to be discussed are those routines which are used for input 
and output to five user supplied peripherals: a keyboard or 
console input device, a console output device (such as a 
video display or Teletype), a paper tape reader, a paper tape 
punch, and a line printer or hard copy output device. 
Because the actual implementation of the interface of these 
devices to your computer may vary from user to user, the 
actual code (machine or assembly language) for the data 
transfer is not supplied with FDOS. However, FDOS does 
make all programs which use these interface routines (Cl, 
CO, RI, PO, LO, CSTS) conform to a common standard, 
allowing programs written on one FDOS system to run 
with no modification on any other FDOS system. For 
instructions on actually interfacing your particular device 
to FDOS, see Appendix G. The following descriptions 
assume that the software interfaces to all 1/O devices have 
been implemented in your FDOS system. 


Console Output (CO) 


Calling routine CO sends exactly one ASCII character to 
the Console Output device. The ASCII character you wish 
to print must be placed in the C register before calling CO. 
Upon return from the CO routine, the Accumulator and the 
status flags will be changed. No other registers will be 
changed. If you are running a 10 character per second 
terminal, then typically one-tenth of one second will 
elapse between when you call CO and when CO returns 
to your program, so be sure that no critical timing pro- 
cesses are taking place during a call to CO. 


Console Input (C1) 


Calling routine Cl will retrieve exactly one ASCII 
character from the Console Input or keyboard device. 
The ASCII character will be returned to your program 
in the A register (Accumulator). Cl causes the Accumu- 
lator and the status flags to change from their values 
before Cl was called. No other registers will be changed. 
Once Cl is called, the computer will stay in the routine 
until a key is available from the keyboard. If a key was 
typed just before the call to Cl, the value will probably 
be stored in the hardware interface register, in which 
case the return from Cl will be immediate. Since this 


is an indeterminate amount of time spent in the Cl routine, 
make sure that no critical timing processes are taking 


place during a call to Cl. 


Console Status (CSTS) 


Calling routine CSTS will cause the system to examine 
the status of the keyboard to find out if a key has been 
pressed since the last call to Cl. If no key has been pressed, 
then CSTS will return to your program with A=0 (the 
Accumulator cleared). If a key has been pressed, CSTS 
will return to your program with A=OFFH (the Accumu- 
lator set). Note: the PSW (status flags) are not set to indi- 
cate the keyboard status; only the Accumulator contains 
this information. Only the Accumulator and flags are 
changed by CSTS. Return from CSTS is very quick, typ- 
ically within 50 microseconds. CSTS can be used to decide 
whether to call Cl or to continue with your program. If 
CSTS indicates that a key has been pressed, then a call 
to Cl should take a very short time. Calling Cl clears the 
“key available” flag and will cause all future calls of CSTS 
to return a zero (no key hit) until another character is 
typed in on the console by the user. 


Reader Input (RI) 


Calling routine RI is similar in format to calling Cl. 
RI returns the next byte from the paper tape reader (or 
other read device) in the Accumulator, with the carry 
bit cleared. Only the Accumulator and the flags will be 
changed. If the reader is out of paper tape, then RI will 
return with the carry bit set to indicate that either no tape 
has been loaded or the end of the tape being read has been 
found. The length of time taken by RI will vary with 
your peripheral device, but RI will probably take many 
milliseconds to return. 


Punch Output (PO) 


Calling routine PO is similar in format to calling CO. 
The byte that you wish to punch must be placed in the 
C register before calling PO. Upon return from the PO 
routine, the Accumulator and the status flags will be 
changed. No other registers will be changed. The length 
of time that a PO call requires will depend on your pe- 
ripheral device. 


List Output (LO) 


Calling routine LO is similar in format to calling CO. 
Enter the ASCII value that you wish to send to your 
list device in the C register. Upon return from the LO 
routine, the Accumulator and the status flags will be 
changed. No other registers will be changed. 


Memory Check (MEMCHK) 


The MEMCHK routine is used by any program that 
needs to know the amount of available memory. Avail- 
able memory is defined here to be the amount of non- 


F write-protected programmable memory which is con- 
tiguous (with no gaps) starting at location 0000 and end- 
ing before the first byte of FDOS. The format of this 
routine is slightly inconvenient, but it is an exact func- 
tional duplicate of the Intel standard memory check 
routine, and therefore can be used with much of the 


Intel library without any modification. It is called in 
this fashion: 


CALL MEMCHK ;FIND THE TOP OF 


;AVAILABLE MEMORY 


Upon return from MEMCHK, only the A, B, and PSW 
registers have been changed. A and B form an address 
with B the most significant byte. This address is 63 bytes 
below the highest available memory byte. No other regis- 
ters and no memory locations are left changed by MEMCHK. 
Examples of programs which would call MEMCHK would 
include an editor (to determine the size of the edit buffer), 
an assembler (to determine allowable symbol table size), 
and BASIC (to determine program buffer size). 


Text Type (TXTYP) 


The TXTYP routine is a straightforward routine which 
prints out a stream of text to the console output device (via 
the CO routine just discussed). The first byte of the text 
to be printed is pointed to by the HL register pair upon 
entry to the TXTYP routine. All of the text starting at M 
(the location pointed to by HL) until the byte before the 
first zero byte, or until and including the first text byte 
with the most significant bit set, will be printed. 

Example 3.1 will print the following out onto the 
system console: 


<er><df> 
TEXT STREAM ONE<er><Jf> 


TEXT STREAM 2 


Upon return from TXTYP to the calling program, regis- 
ters A, C, H, L, and PSW will have been changed. 


Text Input (TXTIN) 


The function of the TXTIN routine was described 
briefly in Pass 2 in Buffered Command Strings; TXTIN 
is the routine which buffers the command strings. If the 
user’s program requires some input from the system con- 
sole, calling TXTIN (instead of multiple calls to Cl) will 
allow the input text to be buffered and edited. The user 
calls TXTIN simply by: 

CALL TXTIN ;GET A BUFFERED STRING IN 

Upon being called, TXTIN proceeds to collect a stream 
of characters from the console input device (using the 
Cl routine internally). During this buffering operation, 
TXTIN recognizes three special editing characters: Rubout, 


Control-R and Control-X. Rubout deletes the last character 
from the buffer, Control-X (*X) resets the buffer to empty, 
and Control-R (*R) causes the current buffer to be printed 
out in the manner that the computer perceives it. These 
actions are explained in more detail with examples in 
Pass 2. When a carriage return or line feed is entered from 
the console, or when the input buffer area overflows 
(buffer size is assembled as 64 characters in this book), 
TXTIN returns to the calling program. The TXTIN rou- 
tine leaves the edited, buffered input character string in 
the TXTIN buffer area for later access by the TI routine 
(described below). Only the A and the PSW registers are 
modified by TXTIN. 


TXTIN is very convenient for the user in order to buffer 
input text and allow correction of mistakes with little or no 
effort on the part of the user’s program. TXTIN is normally 
used to input a command or a disk file name or some other 
data that must be hand entered each time a program is run. 


Tl 


TI is a partner to TXTIN. After a corrected text stream 
has been buffered by TXTIN, TI is used to read the buffer 
back to the program requesting it. Tl is used in the same 
manner as Cl or RI. The first call of TI after a call of 
TXTIN will return the first character from the TXTIN 
buffer (the first character typed in) in the Accumulator. 
Successive calls to TI will return successive characters 
from the buffer. Continued calls of Tl beyond the end 
of the data typed in (terminated by the first carriage 
return entered) will each return a carriage return charac- 
ter (ODH) in the Accumulator. 

Examples of the last three User Accessible Routines 
(UARs) are given in example 3.2. 

One final characteristic of TI is that just before re- 
turning from TI to the calling program, the character 
returned in the Accumulator is compared with 20H (a 
space) to set the PSW. This allows the user to detect either 
spaces (Z flag=1) or any carriage control characters (S flag 
=1). 

TI is never used without calling TXTIN first. TI only 
changes the A and PSW registers. 


TEXT2: DB ODH,OAH, ‘TEXT STREAM 2',0 
TEXT1: DB ODH.0AH; ‘TEXT STREAM ON’ , ‘E’ +80H 
TYPE:  LXI H,TEXT1 

CALL TXTYP 

LXI H,TEXT2 

CALL = TXTYP 


Example 3.1: An example of the use of the TXTYP 
routine. 
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Reading in a Disk File 


This section of Pass 3 presents a method of reading 
data from a file on a disk into the user’s program. The 
FDOS routine which performs the actual data transfer 
looks identical to the RI (paper tape reader) routine. 
This similarity is quite intentional. Most existing soft- 
ware for microprocessors is written to incorporate a single 
byte at a time (bytewise) transfer in or out (from a byte 
at a time paper tape reader or punch). Reproducing (as 
nearly as possible) the RI and PO format for FDREAD 
and FDWRT (Floppy Disk READ and WRiTe) allows the 
user to convert existing software to a disk system with 
as little effort as possible. 

With a paper tape reader, as soon as the tape is loaded 
the data selection process is complete. The only data 
available to the reader is whatever data is present on this 
tape. After a particular disk is loaded, however, there 
still remains the process of selecting which disk file on 
which disk drive to read the data from. Additionally, 
once the file to be read is selected by name, it is possible 
that no such file exists on the selected disk. Once the file 
name is specified and the file is found on the proper disk, 
data transfer can take place in the same format as from the 
paper tape reader. This format is to return the next byte 
of data from the file in the Accumulator on each call of 
FDREAD. When the end of the disk file is detected, as 
when the end of the paper tape is found in the reader, the 
carry bit is set upon return from the FDREAD routine. 
As with RI, FDREAD changes no registers other than A 
and PSW. 

The main difference between a paper tape reading 
routine and a floppy disk file reading routine, then, will be 
in the beginning where the file name is specified and 
searched for. Beyond that point, the routines should be 
very similar. 

To read a disk file, the programmer must use four FDOS 
file handling routines (FILNAM, LOKFIL, OPNIN, and 
FDREAD) and one of the User Accessible Addresses 
(REDFIL). The easiest way to explain the function of these 
user routines and address is with an example. Example 3.3 
allows the user to type in the name of a disk file, following 
which the computer punches the file onto paper tape. 

The excess of labels in example 3.3 is simply for pur- 
poses of description. The actual function of the program 
is described here: 


ASKNAM thru BADNAM: Four messages to be typed 
to the console to alert the user to what is happen- 
ing in the program. 

PUNCH thru PUNO2: This causes the console to type 
a request for the name of the file that is to be 
punched out. 

PUNO3: Reads the file name in from the console de- 
vice, with buffering and editing as needed. 

PUNO4, PUNOS: Transfers the file name from the 
TXTIN buffer to the system disk input buffer (in- 
visible to the user). 

PUNO6: Causes a branch to NAMBAD if an invalid 


file name was entered. 

PUNO7, PUNOS8: Checks to see if this file name exists 
on the specified disk. 

PUNO9: Branches to SUCHNO if the specified file 
does not exist on the specified disk. 

PUN10, PUN11: Prepares the requested file for up- 
coming input operations. 

PUN12: Punches a six inch blank leader onto the 
paper tape. 

PUN14: Reads one byte from the specified disk file 
into the accumulator, and sets the carry bit if 
the end of the file is found. 

PUN15: Transfers control out of the “read one, 
punch one” loop when the end of the disk file has 
been reached. 

PUN16, PUN17: Causes the data byte just read from 
the disk to be punched out onto paper tape. 

PUN18: Continues the ‘‘read one, punch one”’ loop. 

EQF: Punches a six inch blank trailer on to the end 
of the paper tape. 

PUN19, PUN20: Types the successful completion 
message to the user on the system console. 

PUN21: Returns control to FDOS. 

NAMBAD thru PUN24: Types out a message to alert 
the user to the fact that an improperly typed 
name was entered, then returns control to FDOS. 

SUCHNO thru PUN26: Types out a message to alert 
the user that the requested file name did not exist 
on the specified disk drive, then returns to FDOS. 

LEADER thru PUN32: Punches 60 null bytes to 
form a 6 inch blank leader or trailer. 


This example uses the User Accessible Routines (UARs) 
TXTYP, TXTIN, FILNAM, LOKFIL, OPNIN, and 
FDREAD, and the User Accessible Address REDFIL. 
Further details of the operations of FILNAM, LOKFIL, 
OPNIN, and REDFIL will be deferred until Pass 5. The user 
does not need to know how they work in order to use these 
UARs at this level of sophistication. 

A few noteworthy features of example 3.3 are instruc- 
tive. The only way to specify the name of the disk file to be 
punched is for someone (the operator) to type the name 
into the console. The name cannot be included in the 
punch program, nor can the punch program modify the 
name in any way. While this is slightly restrictive, it elim- 
inates describing and understanding the format of file 
specifications in data buffers. 

This example contains no memory area for data buffers. 
Data is transferred one byte at a time from the disk drive 
to the punch. 

Only one disk file can be read in at any time. Each call 
to FDREAD returns the next byte of data from whatever 
file was last specified by the TXTIN, FILNAM, LOKFIL, 
and OPNIN combination of routines. While this prevents 
complex data manipulations such as file merging or file 
comparison, it does simplify both the punch program and 
the explanation of the punch program. Most file handling 
programs that you will write should not require more than 
one file being read at any one time. The following chapters 
describe methods for keeping over 200 different files open 


QUEST: DB A NEW FILE? (Y OR N)',0 Example 3.2: An example of the use of the TXTYP, 
TXTIN, and TI User Accessible Routines (UARs). 

ASK: LX! H,QUEST the text to type 

CALL TXTYP ;ask the question 

CALL TXTIN ;buffer the response 

CALL Ti iget the first letter of the response 

CPI i ;Was ita Y ? 

JZ YES 7yes, goto YES 

CPI ‘N’ ;was itan N ? 

JZ NO 7yes, goto NO 

JMP ASK ;neither, therefore error, so try again 

ORG 10H 

ASKNAM: DB 13,10, ‘WHAT FILE DO YOU WISH TO PUNCH?’ ,O 

NOSUCH: DB 13,10 ‘NO SUCH FILE EXISTS!’ ,O 

OKDONE: DB 13,10, ‘JOB IS FINISHED’ ,O 

BADNAM: DB 13,10, ‘THIS IS A BAD FILE NAME!’ 0 

PUNCH: LXI SP,800H 

PUNO1: LXl H,ASKNAM 


PUNO2: CALL TXTYP 
PUNO3: CALL TXTIN 
PUNO4: LHLD REDFIL 
PUNOS: CALL FILNAM 
PUNO6: JC NAMBAD 
PUNO7: LHLD REDFIL 
PUNO8: CALL LOKFIL 
PUNOS: JC SUCHNO 
PUN10: LHLD REDFIL 
PUN11: CALL OPNIN 


PUN12: CALL LEADER 


PUN14: CALL FDREAD 


PUN15: JC EOF 
PUN 16: MOV CA 
PUN17: CALL PO 
PUN 18: JMP PUN14 
EOF: CALL LEADER Example 3.3: An example of a routine which accepts a disk 
PUN19: — LX! H,OKDONE file name as input and then punches the file onto paper 
PUN20: CALL TXTYP ‘ 
PUN21: JMP FDOS tape. 
NAMBAD: LXI H,BADNAM 
PUN23: CALL TXTYP 
PUN24: JMP FDOS 
SUCHNO: LXI H,NOSUCH 
PUN25: CALL TXTYP 
PUNZ26: JMP FDOS 
LEADER: MVI B,60 
LEAD1: MVI C,0 
PUN29: CALL PO 
PUN30: DCR B 
PUN31: JNZ LEAD1 
PUN32: RET 
END 


——a—_____ ss 
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for reading at any time, if such an operation ever seems 
desirable. 

The programmer who wishes to write software that reads 
disk files can now do so in a rudimentary manner. Simply 
copy the parts of example 3.3 that apply to the job you 
wish to perform. Pass 5 will give full details on these opera- 
tions if you run into any problems. 


Writing a File to the Disk 


This section, like the preceding section on reading a file 
from the disk, describes the “how to” of putting a file on 
the disk, but without any detailed explanation as to why 
anything is being done. Actual data transfer to the disk is 
performed by the FDWRT User Accessible Routine (UAR). 


FDWRT is identical in nature to the PO, LO, and CO 
routines; the byte to be put out is loaded into register C 
and the routine is called. This duplication of routine format 
eases the conversion of existing paper tape oriented soft- 
ware to get your programs on line and operational faster 
and with fewer errors. 

There are two major differences between FDWRT and 
PO, LO, and CO: before the first call to FDWRT, a series 
of UARs must be called to set the file up for output; and 
after the last call to FDWRT, one final UAR must be called 
to properly end the file. These start and finish routines can 
be considered analogous to putting a leader and trailer 
section onto a paper tape for ease of handling. 

Example 3.4 shows how the data read in from the paper 
tape reader can be copied to a disk file. The name of the 
disk file is typed in by the operator when the program is 
run. When the paper tape reader finds the end of the paper 


ORG 10H 
ASKNAM: DB 
ALREDY: DB 
OKDONE: DB 
BADNAM: DB 


READ: LX! 
REDO1: LX! H,ASKNAM 
REDO2: CALL TXTYP 
REDO3: CALL TXTIN 


SP,800H 


REDO4: LHLD WRTFIL 
REDOS: CALL FILNAM 
REDO6: JC NAMBAD 
REDO7: LHLD WRTFIL 
REDO8: CALL LOKFIL 
REDO9: JNC REDYAL 
RED10: LHLD WRTFIL 
RED11: CALL OPNOT 


RED12: CALL Ri 
RED13: JC EOF 
RED14: MOV C,A 


RED15: CALL FDWRT 
RED16: JMP RED12 
EOF: LHLD WRTFIL 
RED18: CALL CLSOT 
RED19: LX! H,OKDONE 
RED20: CALL TXTYP 
RED21: JMP FDOS 
NAMBAD: LXI H,BADNAM 
RED23: CALL TXTYP 
RED24:  JMP FDOS 
REDYAL: LXI H,ALREDY 
RED26: CALL TXTYP 
RED27: JMP FDOS 

END 


13,10, ‘WHAT DO YOU WISH TO NAME THE FILE?’ ,O 
13,10, ‘THIS FILE NAME ALREADY EXISTS!’ ,O 
13,10, ‘THE JOB IS FINISHED’ ,O 

13,10, ‘THIS IS A BAD FILE NAME’ ,O 


Example 3.4: An example of a routine that copies a file 


from paper tape to disk, 


tape, the disk file is closed. A line-by-line description of 
what this example does follows: 


ASKNAM thru BADNAM: Four messages to be printed 
on the console to alert the user to what is happening. 

READ thru REDO2: This causes the console to printa 
request for the name of the file to be created and 
copied from the tape reader. 

REDO3: Reads the file name in from the console 
device. 

RED0O4, REDOS: Transfers the file name from the 
TXTIN buffer to the system disk output buffer 
(invisible to the user). 

REDO6: Causes a branch to NAMBAD if an invalid 
file name was typed in. 

REDO7, REDO8: Checks to see if this file name 
exists on the specified disk drive. 

REDO9: Branches to REDYAL if the specified file 
already exists on the specified disk drive. 

RED10, RED11: Enters the specified file into the 
directory of the specified disk. This creates the 
file on this disk. 

RED12: Reads one byte from the paper tape reader 
into the accumulator. 

RED13: Transfers control of the “read one, write 
one” loop when the end of the paper tape is 
sensed. 

RED14, RED15: Puts the data byte to be written into 
the C register and sends it out to the disk file. 

RED16: Loops to continue the “‘read one, write one” 
loop. 

EOF, RED18: Closes the output file. Closing the file 
consists of making sure that all of the data was 
sent out to the disk properly and recording the 
total length of the new file on the disk. 

RED19 thru RED21: Types the successful completion 
message to the user on the system console and 
returns control to FDOS. 

NAMBAD thru RED24: Types out a message to alert 
the user to the fact that an improper file name 

REDYAL thru RED26: Types out a message to alert 
the user that a file with the specified name already 
user that a file with the specified name already 
exists on the specified disk, and therefore another 
file of the same name cannot be created. 


This example is similar to the example of how to read 
data from the disk (example 3.3). Most of the same UARs 
were used; only the OPNOT, FDWRT, and CLSOT routines 
and the WRTFIL User Accessible Address are different 
from the data read example. The detailed explanation will 
be deferred until Pass 6. The user need only know how to 
use these routines, not exactly how they work, in order 
to make proper use of them. 

A review of the preceding example of how to write data 
onto the disk brings out some interesting points. Again, the 
only way to specify the name of the file to be created on 
the disk is to have the computer operator type it in (file 
name, extension, and drive number) through the console. 

No memory area for data buffers is needed; the user 


deals with only one byte of data at a time. Only one file 
can be created on the disk at a time. And before creating 
a second file, the first must be finished and closed (by the 
CLSOT call). Later chapters will describe how, by allocat- 
ing multiple data buffers, multiple files can be created 
simultaneously. 

There are two final points to make in reviewing the data 
write Operation. Although the FDWRT routine can be used 
simply and easily in place of a single character paper tape 
punch routine, special groups of instructions must be 
placed before the first use of FDWRT and after the last 
use of FDWRT. When adapting example 3.4 to your own 
use, put the block of instructions from REDO] to RED11 
inclusive where they will be executed once and only once 
before your first call to FDWRT. Secondly, put the two 
instructions labeled EOF and RED18 where they will be 
executed once and only once after the last call to FDWRT. 
This assures that the file will be stored properly on the disk. 

Having the ability to use the FDOS file management 
routines (an all inclusive catagory for the User Accessible 
Routines described in this chapter) gives the programmer 
a lot of flexibility at this level. Consider the instance where 
you do a lot of programming in BASIC. In this case you 
might like to store and later retrieve your BASIC programs 
by name (names like TREK, CHKBK, WUMPUS). Assume 
that you know nothing about the internal workings of your 
BASIC (a frequent situation) except where the cassette (or 
paper tape) load and store (cload and csave, plist and read, 
etc.) routines are in BASIC. Substitute one call to your 
personal interface program for the routine in BASIC that 
sends a single byte to the tape (or punch) unit. Substitute 
a Call to a different part of your personal interface program 
for the routine in BASIC that reads a single byte in from 
the tape (or reader) unit. 


Saving a BASIC Program 


When BASIC branches to your personal interface pro- 
gram instead of recording a byte on cassette, you must 
determine if this is the first byte, the last byte, or some 
intermediate byte of the program to be recorded. If this is 
the first byte, then store the byte temporarily, and call the 
routines shown in REDO1 to RED11 of the paper tape 
read example 3.4. These routines will request a file name to 
be typed in, create a file with that name on the disk and 
set that file up to accept data from the BASIC interpreter 
through your interface program. After this has been done 
successfully, retrieve the temporarily stored byte and send 
that first byte to the disk via the FDWRT routine. 

All intermediate bytes may be sent directly to the disk 
using FDWRT. 

When the last byte is sent out, after the byte has been 
sent to FDWRT, the instructions shown in EOF and 
RED18 of example 3.4 can be performed to properly finish 
the file. Make sure that all registers are preserved and 
restored during each of these steps to avoid any problems 
with your version of BASIC. 
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Recalling a BASIC Program 


When BASIC branches to your interface program, 
instead of reading a byte from the cassette, you must 
determine if it is the first byte requested by this load 
operation, or if it is any other byte. If it is the first byte, 
then you should execute the set of instructions labeled 
PUNO1 through PUN11 in the paper tape punch example 
3.4. This requests the filename from the user and sets up 
the parameters needed to read the file. After setting up 
the file, use FDREAD to retrieve the first byte of the file, 
and return it to BASIC in whatever format is expected. 

All other calls to this part of your interface program 
should just perform one call to FDREAD and return the 
byte read in to the BASIC program. As with the BASIC 
program save example, make sure to save and restore all of 
the registers needed by your BASIC interpreter. 

The two preceding descriptions were intentionally 
general and perhaps rather vague. Since so many BASIC 
interpreters exist, it is impossible to describe each speci- 
fic case. Some BASICs do not have cassette store and load 
routines. In this instance, clever manipulation of the BASIC 
LIST command in conjunction with diverting all calls of 
console output to the FDWRT routine, and pretending 
that the FDREAD routine is sometimes the keyboard 
input device will allow you to save and reload BASIC 


programs on the disk using FDOS. 

Included in example 3.5 is a specific listing of a program 
that works quite well to interface between FDOS and 
MITS 8 K BASIC version 3.2 for cassette. This is an ex- 
ample of the type of simple interface program possible for 
a typical BASIC. 


Summary 


This chapter described all of the simple, cookbook 
routines needed to use FDOS to advantage without having 
to learn or worry about buffer space, file structure, data 
blocking or unblocking. Descriptions were presented of the 
User Accessible Routines (UARs) MEMCHK, TXTYP, 
TXTIN, and TI; what they are, what they do, and how to 
use them. Intentionally vague descriptions were given of 
FILNAM, LOKFIL, OPNIN, OPNOT, FDREAD, FDWRT, 
and CLSOT. We showed how, using the routines described, 
but without necessarily understanding these routines, disk 
files could be read and written. Finally, in an attempt to 
prove this knowledge is useful, examples were given to 
demonstrate that this is sufficient knowledge for inter- 
facing BASIC to FDOS. In a similar manner, an editor, 
assembler, or compiler could be interfaced, without having 
to learn any more FDOS internals. 
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Example 3.5: A listing of a program that successfully inter- 
faces FDOS to MITS 8 K BASIC version 3.2. 


;FDOS ROUTINES (AS OF 4—JAN—77) 


FDOS EQU ODOOOH 
FDOSP EQU FDOS + 28H 
REDFIL EQU FDOS+2AH 
WRTFIL EQU FDOS+2CH 
RDFLNM EQU FDOS+2EH 
WRFLNM EQU FDOS+30H 
BITMAP EQU FDOS+32H 
BEGIN EQU FDOS+34H 
Cl EQU FDOS+37H 
RI EQU FDOS+3AH 
co EQU FDOS+3DH 
PO EQU FDOS+40H 
LO EQU FDOS+43H 
CSTS EQU FDOS+46H 
RESTRT EQU FDOS+49H 
INIT EQU FDOS+4CH 
FDREAD EQU FDOS+4FH 
FDWRT EQU FDOS+52H 
BYTIN EQU FDOS+55H 
BYTOT EQU FDOS+58H 
BLKIN EQU FDOS+5BH 
BLKOT EQU FDOS+5EH 
RNDOT EQU FDOS+61H 
OPNIN EQU FDOS+64H 
OPNOT EQU FDOS+67H 
CLSOT EQU FDOS+6AH 
FILNAM EQU FDOS+6DH 
LOKFIL EQU FDOS+70H 
TXTYP EQU FDOS+73H 
Tl EQU FDOS+76H 


;Starting address of the FDOS being used 


ssystem internal SP 

;system input buffer 

;system output buffer 

;immediate input buffer 

simmediate output buffer 

;block occupancy bit map area 
;FDOS restart 

;console input 

;reader input 

;console output 

;Punch output 

jlist output 

;check console status 

;restart address 

zero all disks 

byte in from system input file 
;byte out to system output file 
byte in from file at (HL) 

;byte out to file at (HL) 

3280 byte block into (HL) 

3280 byte block out of (HL) 
;Output a random block, no linkages 
open file at (HL) for input 

open file at (HL) for output 

iclose file at (HL) from output 

get a file name from TI stream 
;look for the file name at (HL) 
;type out text starting at (HL) onto CO 
*get the next character from the TXTIN string 


TXTIN 
DELETE 
RENAME 
MEMCHK 
K2SP 


’ 


TOPRAM 
V32 
v40 


NUMOS 
COUT 
CIN 
CSTS1 
CSTS2 
CLOAD 
CSAVE 


NUMOS 
COUT 
CIN 
CSTS1 
CSTS2 
CLOAD 
CSAVE 


;input a corrected line from Cl 

;delete a file from the disk 

;rename a file in the directory 

;find the upper bound of available memory 
;this is approximately the available stack 


;top of users memory 
;conditional assembly for version 3.2 
jconditional assembly for version 4.0 


;number of terminal OS 
jaddresses of the various routines 


EQU FDOS+79H 
EQU FDOS+7CH 
EQU FDOS+7FH 
EQU FDOS+82H 
EQU FDOS+OFFFH 
-TITLE BASIC additions for FDOS 
DATE 25—FEB—78 
EQU 5000H 

EQU OFFFFH 

EQU 00000H 

IF V32 

EQU 3 

EQU 4D0H 

EQU 4DBH 

EQU 549H 

EQU 5E9H 

EQU 1007H 

EQU 1014H 

ENDIF , 

IF v40 

EQU 10 

EQU OE01H 

EQU 0E10H 

EQU OEADH 

EQU OFBEH 

EQU 22F5H 

EQU 2302H 

ENDIF 


:make all BASIC Cl, CO, CSTS use the FDOS UARs 


ORG 
PUSH 
MOV 
CALL 
POP 
POP 
DB 
RET 


ORG 
CALL 
DB 
ANI 


ORG 
CALL 
ORA 
CNZ 


ORG 
CALL 
ORA 
RZ 


COUT 

B 

CA 

co 

B 

PSW 
0,0,0,0,0,0,0 


Cl 
0,0,0,0,0,0 
7FH 


CSTS1 
CSTS 


A 
OFC3H 
CSTS2 


CSTS 
A 


shere are the MITS CSAVE, CLOAD routines 


ORG 
CALL 
RET 


ORG 
CALL 
RET 


CLOAD 
NAMIN 


CSAVE 
NAMOT 
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;this is the top space for the CSAVE, CLOAD interface . 
LX1 ? 
if PUS 
ORG TOPRAM—100H XCHG 
PCHL 
NAMIN: CALL SPCHNG_;swap 4 re to more room 
PUSH PSW jget the CLOAD file name 
LHLD REDFIL SPRET: POP 
NAMI1: CALL FLNMIN SPHL 
JC NAMI1 POP 
CALL OPNIN POP 
LXI H,REDBYT POP 
SHLD CLOAD+1 RET 
POP PSW 
JMP REDBYT+3 
NUMZRO: DB 
FILASK: DB 
NAMOT: CALL SPCHNG ;get the CSAVE file name 
PUSH PSW 
LHLD WRTFIL END 
NAMO1: CALL FLNMIN 
JNC NAMO1 
CALL OPNOT 
LXI H,WRTBYT 
SHLD CSAVE+1 
POP PSW 
JMP WRTBYT+3 
FLNMIN: PUSH H ;save the buffer pointer 
LXI H,FILASK ;type out a file name request 
CALL TXTYP 
CALL TXTIN ;buffer the file name in 
POP H using this pointer, 
CALL FILNAM _ ;get the file name from the text 
JMP LOKFIL = ;then do acall and return to look for file 
REDBYT: CALL SPCHNG se; all attempts to read a byte from 
CALL FDREAD cassette end up here (after the first) 
LXI H,NUMZRO 
ORA A 
JZ REDB1 
MvVI M,NUMOS 
JMP SPRET 
REDB1: DCR M 
JNZ SPRET 
LXI H,NAMIN 
SHLD CLOAD+1 
JMP SPRET 
WRTBYT: CALL SPCHNG ;all attempts to write a byte to cassette 
MOV CA ;wind up here (after the first one) 
CALL FDWRT 
LXI H,NUMZRO 
ORA A 
JZ WRTB1 
MvVI M,NUMOS 
JMP SPRET 
WRTB1: DCR M 
JNZ SPRET 
LXI H,NAMOT 
SHLD CSAVE+1 
LHLD  WRTFIL 
CALL CLSOT 
JMP SPRET 
SPCHNG: XTHL effectively push H 
PUSH D 
PUSH B 
XCHG 
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H,O 

SP calculate old SP 
SP,K2SP—12H 
H 


;return to caller 


xr0on =r 


0 
‘FILE NAME?’,’ ‘+128 


PASS 4: Disk Data Block and 


File Buffer Area Structures 


The purpose of Pass 4 is to describe the FDOS file struc- 
ture; that is, how data and programs are actually stored on 
the disk. If you keep the examples of file data transfer from 
Pass 3 in mind, it will be easier to understand why certain 
operations are performed the way they are. Pass 4 describes 
data storage on the disk, file organization, and directory 
organization. 


Data Storage on the Disk 


Because of the mechanical construction of a floppy disk 
drive (or a rigid disk drive), it is advisable to transfer data 
to and from the disk in “blocks” of data. A block of data 
is a grouping of many bytes of data. Usually a block of data 
contains at least 128 bytes, but may contain as many as 
10,000 bytes on a double-density disk drive. If you try to 
transfer small blocks of just a few bytes, or even try to read 
or write one byte at a time, the total amount of data that a 
single disk can hold will drop drastically. Even with sophis- 
ticated software and hardware, transferring single bytes to 
and from the disk will reduce the disk capacity to a few 
percent of what can be stored using blocks of 128 or more 
bytes. 

To keep the software simple and straightforward (a 
synonym for reliable), the number of bytes in all blocks of 
data stored on the disk should be the same. For purposes 
discussed in this chapter, FDOS operates with a block size 
of 280 bytes per block. All data blocks on the disk contain 
280 bytes of information. 

Immediately a problem arises. Very few of the data files 
or programs are likely to be exactly 280 bytes long; some 
will be shorter and most files are likely to be longer. Because 
of these facts, a basic organizational format for data files 
must be defined before further description of the FDOS file 
system is possible. 


Data Blocks 


All data on a disk is stored in data blocks. Each block is 
uniquely defined by three values: disk drive number, track 
number, and sector number. 

A brief description is needed at this point. Disk drive 
number has been defined before, but no mention has been 
made of tracks or sectors. A floppy disk drive can access 
many different tracks (concentric circles of magnetically 
stored data on the disk). A full-size (8 inch) floppy disk 
usually has 77 tracks numbered 0 through 76. A 5 inch 
floppy disk typically has 35 or 40 tracks, numbered 0 
through 34 or 39. The read/write head of the drive may be 
positioned at any one of these tracks at any time, and 
multiple drives can be positioned on different tracks 
simultaneously. 

Each track is divided into many equal parts called 
sectors. If the division (sectoring) is accomplished by 
physical holes (sector holes) punched in the disk itself, 
the disk is termed “‘hard-sectored.” If the sectoring is 
accomplished by specially written data, magnetically 
recorded on the disk itself, the disk is said to be “‘soft- 
sectored.” Hard-sectored 8 inch floppy disks contain 
32 sectors on each track, while soft-sectored 8 inch disks 
contain 26 sectors. The 5 inch floppy disks may contain 
10 or 16 hard sectors, while the soft-sectored format is not 
standard. 

The sectors described in the preceding paragraph were 
each intended to store one data block of 128 bytes. The 
FDOS in this manual uses 280 byte blocks on hard-sectored 
disk drives, either 8 inch or 5 inch size. Each data block 
therefore spans two disk sectors. Since a data block is 
defined by drive number, track number, and sector number, 
only even sector numbers (0 to 30 for 8 inch disks, 0 to 
14 for 5 inch disks) are used by FDOS to assure that data 
blocks begin and end on the proper positions on the disk. 
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This means that 8 inch disks have 16 blocks on each track, 
and 5 inch disks have 8 blocks per track. 

Finally, tracks 0 and 1 are reserved on all disks for the 
operational copy of FDOS. Therefore, only track numbers 
from 2 through 34, 39, or 76 (depending on the disk drives 
being used) are legal. This gives an 8 inch disk 16X 75=1200 
blocks, and a 5 inch disk has 33X8=264 or 38X8=304 
blocks per disk. 

Needless to say, the only legal disk drive numbers are 
those numbers for which there is an actual disk drive 
interfaced to the system, and which has a disk loaded in 
the drive. 


Data Block Organization 


We now know what a data block (also referred to simply 
as a block) on a disk is and how it is located by drive 
number, track, and sector. The next question is: How is 
data stored within blocks and in data files? Because a file 
may contain more than 280 bytes, it is obvious that more 
than one block may be needed to store a file. In order to 
read a file back from the disk, then, FDOS must know 
which blocks hold the data, and in what order. FDOS 
uses a common and simple scheme known as a linked file 
structure. 

A linked file structure simply means that a file may 
consist of any number of blocks, and that each block in 
a file contains a linkage, or pointer, to the next block 
in the file. The last block does not require a linkage, but 
must indicate that it is the last block in the file. A file in 
FDOS which contains 700 bytes of data will fill two blocks 
and occupy a part of a third block. The first block of this 
file would point to the second block by a “forward link- 
age”’; that is, the first block has a record of the track and 
sector of the second block. The second block in turn would 
contain the track and sector of the third block. The third 
block has no forward linkage because it is the last block 
in this file. By setting the forward linkage to point to track 
0 sector 0 (defined as a reserved area, and therefore an 
invalid block address) FDOS declares that the third block 
is the last block of the file. 


Table 4.1: File block format for disks. 


Housekeeping 


Suddenly you realize that not all of the aforementioned 
280 bytes can be used to store useful data (file data). 
Two bytes have just been used to record where to look for 
the next block in a multi-block file. This leaves only 278 
bytes in which to store data. 

Examining table 4.1, you will see that in reality far 
fewer than 278 bytes are used to store data. Bytes 21 
through 276 are used to store 256 total bytes of data 
in each block. 256 is chosen because it is the number of 
different bit patterns representable by an 8 bit byte (28). 

If only 256 bytes are used for data storage, this leaves 24 
bytes to wonder about. These are called the housekeeping 
bytes. 

The purpose of housekeeping bytes is to provide all of 
the information needed by FDOS to ‘‘keep house,” i.e., the 
information FDOS needs to organize files on the disk, 
keep track of how long the files are, where they are located, 
and whether they contain valid data. It should be noted 
that all blocks of data have exactly the same format for 
data and housekeeping information. Blocks from any data 
file or any stored program, or from the disk directory 
or bit map (to be discussed later), all have exactly the 
same format. 


Block Format 


At this point a full explanation will be made of the 
format of the housekeeping information on a typical block 
of a typical file on a typical disk. Refer to table 4.1 for 
the byte numbers described below. 

Bytes —17 thru —2 are zeroes on the disk. This par- 
ticular detail is part of FDOS because FDOS as 
presented in this book is written for the hardware 
described in Appendix K. These bytes may change 
value depending on your hardware and driver 
software. The zeroes on the disk are used by the 
hardware to synchronize the disk bit clock to the 
actual data to be read. 

Byte —1 is the data synchronizing or ‘‘sync” byte. 
In this particular FDOS implementation, the 
sync byte is 81H. This byte is used to synchronize 
the data receiver to the proper set of 8 bits in the 
incoming bit stream. If your interface hardware 
differs from that described in Appendix K, then 
the value of the sync byte may also change. 

Bytes 0 thru 8 contain the 6 ASCII character file 
name and 3 ASCII character file extension of the 
file name used to create the file that this block is 
a part of. Note that this may be different from 
the current name of the disk file as stored in 
the directory. A particular function of FDOS, 
to be described later, gives a new name toa file 
by changing the file name in the disk file direc- 
tory, but not changing the name on each block 
of the file (to save time). The file name given 


this file at the time of Creation, however, will 
always remain in the first 9 bytes of each block 
of data on the disk in ASCII. 

Byte 9 contains an integer number from 0 to 7 
indicating which disk drive this file was origi- 
nally created on. Because the disk can be removed 
from one drive and reinserted into another, this 
number may not reflect the current disk drive 
that the disk is loaded in. 

Byte 10 contains the track number that this block 
is recorded on. If the block is located on track 
29 (decimal), then byte 10 of the block will 
have a 1DH (=29.) stored in it. The track number 
is a number between 2 and 34, 39, or 76, depend- 
ing on drive type. 

Byte 11 contains an even number telling which sector 
this data block starts at. This is an even number 
between 0 and 14 or 30, depending on drive type. 

Bytes 10 and 11 together form the track and sector 
number of the data block under our scrutiny. 
If, upon reading this block into the computer, 
the track and sector numbers indicated by these 
housekeeping bytes disagree with the track and 
sector that the disk drive was requested (pro- 
grammed) to read, then some error has occurred. 
This block identification (track and sector num- 
ber) allows the computer to confirm that the 
correct block was read in. 


Bytes 12 and 13 are the track and sector numbers 
(respectively) of the reverse linkage. The reverse 
linkage concept has not yet been discussed, but 
it is very simple. In a linked file with many blocks, 
the reverse linkage of any block points to the track 
and sector of the immediately preceding block 
in the file. The first block of a file has no pre- 
ceding block, so the reverse linkage of the first 
block of a linked file is always set to point to 
track 0, sector 0, which is an invalid pointer 
indicating that this is the first block of the file. 

Bytes 14 and 15 are the track and sector numbers 
(respectively) of the forward linkage. In a linked 
file with many blocks, the forward link of any 
block except the last block points to the track 
and sector of the next block in the file. The 
forward linkage of the last block is set to track 0, 
sector 0 to indicate that it is the last block. 

Bytes 16 and 17 are used to denote which block of a 
linked file this block is. The value of byte 16 is 
1 on the first block of a linked file, 2 on the 
second block, and so forth. Byte 17 does not 
change from 0 unless the file is greater than 
255 blocks long. 

Byte 18 is reserved for future expansion of FDOS. 
The user may make use of this byte as is conven- 
ient for his application. 

Byte 19 is used only on the last block of a linked 
file. As described briefly earlier, the average data 
file or program file will not usually fit exactly in 
an integral number of blocks, but will only fill 
part of the last block. The last block will contain 


from 0 to 255 valid data bytes in the data area. 
If the forward linkage bytes (14 and 15) are both 
0, then byte 19 indicates how many valid data 
bytes are in the data area of this block. 

Byte 20 is not used on the disk, but is used in the 
block buffer area to be explained later. 

Bytes 21 thru 276 form the data area, containing 
up to 256 bytes of data. A disk file containing N 
bytes of data will require INT(N/256)+1 blocks to 
hold the data. The data areas of all blocks except 
the last block of any linked file are full. 

Byte 277 is reserved for future expansion of FDOS. 

Bytes 278 and 279 store a 16 bit data check sum. 
The check sum is formed using a binary poly- 
nomial (formula X16 + x12 + x + 1) calculated 
from all of the bytes from byte 0 through byte 
277, and is then stored on the disk as part of 
the data. When the block is read back from the 
disk into the computer, the check sum is calcu- 
lated again from the data just read in. If the calcu- 
lated check sum agrees with the one read in as 
part of the block, then (with a very high degree 
of probability) the data in the block was read 
in without error. If the two 16 bit numbers do 
not agree, then the data just read in is incorrect, 
and appropriate action should be taken. 


Bytes 280 thru 295 are trailing bytes which store no 
useful data. These bytes are included to satisfy 
the interface specifications of the disk drive 
manufacturer. 


Data File Storage Format 


After all of the preceding detail, you may be relieved 
to know that the user does not need to understand, modify, 
or keep track of any of the housekeeping information. 
The user need only avoid changing any of this information, 
while FDOS makes all needed calculations and corrections. 
Pass 4 explains what the data format is, but will not discuss 
any routines or operations that require actual manipula- 
tions of the housekeeping data. The block format is ex- 
plained mainly to provide sufficient background for the rest 
of this pass and for Pass 5 and 6. 

A file of data stored on the disk can be viewed from or 
operated on in many different ways. Because of the avail- 
able routines in FDOS, the easiest and most frequent 
method of viewing data files ignores all of the consider- 
ations of block size, block position, forward and reverse 
linkages, or byte counts. This simple format views the 
data being read from or written to a disk file simply as if 
the file were a paper tape reader or a paper tape punch 
that operates one character at a time (asynchronously). 
The data in a file can then be likened to a paper tape of 
punched data, or data to be punched. The data appears 
as one continuous stream of data, one byte at a time, 
without regard to block boundaries or byte counts. On 
the disk itself the actual data is divided up into groups of 
256 bytes. The first byte of the data would be stored in 
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byte 21 of the first block in the file; the 256th byte would 
be stored in byte 276 of the first block; the 257th byte 
would be stored in byte 21 of the second block of the file, 
and so forth. 

The user’s program calls for bytes from (or sends bytes 
to) a data file one at a time. To the user’s program there 
is no more difference between the 256th and 257th data 
bytes in a file (stored on two different disk blocks) than 
there is between the first and second data bytes of that 
same file. FDOS makes all blocking and unblocking in- 
visible to the user. Blocking refers to the process of storing 
(in memory) data bytes to be written to the disk, until 
a sufficient number of data bytes has accumulated, and 
then writing the entire block out to the disk. Unblocking 
refers to reading in one block of data from the disk into 
memory and returning one data byte at a time to the 
program requesting the data, until the next block needs 
to be called in. 


File Buffer Areas 


The FDOS routines which perform the blocking and 
unblocking operations require an area of memory to store 
the blocks of data between transfers of data to and from 
the disk, and transfers of data to and from the user’s pro- 
gram. In addition to storing the actual data to be trans- 
ferred between program and disk file, various pointers and 
counters must be stored to keep track of where the next 
byte of data to be transferred is in memory, where on the 
disk that next block of data is to be located, and which 
disk drive to transfer the data to or from. This is house- 
keeping data of exactly the same type as described in the 
block format. In order to read a file in from the disk or 
write a file out to the disk, then, FDOS needs to have an 
area of memory set aside to store the data and the house- 
keeping information associated with the transfer. This area 
of memory is called the file buffer area. 

Table 4.2 shows the file buffer area format, which looks 
suspiciously like the file block format. The reason for the 
similarity is simple. The entire file buffer area (with a few 
additions) is written to the disk to form a block on the 
disk. Similarly, the entire file block is read from the disk 
and almost all of it is copied into the file buffer area in 
memory. 


Table 4.2: File Buffer Area format in memory. 


A description of the function of the various data stored 
in the file buffer area as shown in Table 4.2 follows: 


Byte 0 thru 8: The ASCII file name and extension ot 
the file being read or written. 

Byte 9: The device number, the number of the disk 
drive on which the file is being written or read. 

Bytes 10 and 11: The track and sector of the block 
on the disk that this file buffer area was read from 
(during a read operation), or will be written to 
(during a write operation). 

Bytes 12 and 13: The track and sector of the previous 
data block in this linked data file. 

Bytes 14 and 15: The track and sector of the follow- 
ing data block in this linked data file. During a 
read operation, this data comes in from the disk 
data block. During a write operation, this data is 
supplied by FDOS., 

Bytes 16 and 17: Identifies the linked block of data 
in the file to which this file buffer area corre- 
sponds. The first block in the file is numbered 1, 
the second 2, and so forth. 

Byte 18: Reserved for future use. 

Byte 19: Only used during a read operation on the 
last block of data in the file. On the last block, 
byte 19 always indicates the number of valid bytes 
left in the 256 byte data area. 

Byte 20: Contains a number from 0 to 255. This 
number, when added to the address of byte 21, 
gives the address of the next byte to be read from 
or written to the file buffer area, in a single byte 
read or single byte write operation. 


Bytes 21 thru 276: Buffer of 256 bytes of data. 
During file read operations, data is read into this 
area from the disk and then the 256 bytes of 
data are sent out one by one. During a file write 
Operation, this area stores 256 bytes of data 
sent to it one by one, and then the block of col- 
lected data is written onto the disk all at once. 

Byte 277: Reserved for future use. 


Note that there is no check sum associated with the file 
buffer area, as all check sum operations are performed 
internal to FDOS, 

File buffer areas for input (reading a file) are identical 
to file buffers for output (writing a file). If you wish to 
read from two different files, on the same or on different 
disk drives, while simultaneously writing out to a third 
file on any disk drive, then you must put three different 
file buffer areas in your program. That means that you 
must set aside 278 X 3=834 bytes of memory in your pro- 
gram to permit FDOS to perform the two file reads and 
the one file write simultaneously. 

Almost all of the User Accessible Routines (UARs) in 
FDOS which work with the disk files make reference 
to one or more particular file buffer areas. This is neces- 
sary because each FDOS file handling routine is able to 
handle any disk file, so the routine must know what file 
it is operating on. Since each file buffer area is associated 
with only one file, and contains all of the pertinent infor- 
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mation for that file, the program passes the file information 
to the UAR by having the UAR operate on a particular file 
buffer area. 

Before calling a UAR which references a file buffer area, 
you must put the address of the first byte of the file 
buffer area in the HL register pair. If H and L contain 
needed information just previous to calling the UAR, 
then it is the user’s responsibility to save that information 
before loading the file buffer area address into HL. Notice 
that there is no restriction on where a file buffer area 
is placed, in high or low memory or relative to a page 
boundary (a memory location with an address with all 
zeroes in the 8 least significant bits). There is no restric- 
tion on the access or cycle time of the memory used and 
there is no restriction on the number of file buffer areas 
that may exist at any time. If the user has a full 64 K bytes 
of memory available, theoretically over 200 file buffer 
areas could be simultaneously reading and writing data to 
over 200 different disk files on up to 8 different disks. 

FDOS makes use of two file buffer areas which are in- 
ternal to FDOS, one dedicated to reading disk files, and one 
to writing disk files. The read file buffer area is used in 
response to a RUN command. The program file to be run 
is read in to the FDOS read file buffer area, transferred 
to the proper area of memory, and run. The write file 
buffer area is used in response to a SAVE command. 
Data contained in the areas of memory to be saved (indi- 
cated by the LIMITS commands) is transferred into the 


system write file buffer area and then written onto the 
disk. 

When FDOS is not being used to RUN or SAVE (which 
means any time that a user’s program is running), these 
file buffer areas are not needed, and may be used by the 
user’s program. While these buffer areas (referred to as the 
system buffers) may move around from one version of 
FDOS to another, the addresses of the two system buffers 
are always stored in a fixed location within FDOS. As 
you have probably surmised, these are the User Accessible 
Addresses labled REDFIL and WRTFIL used but not ex- 
plained in Pass 3. 


Summary 


FDOS stores all data on the disk in files composed of 
blocks of data. These blocks are 280 bytes long on the 
disk and each block occupies two sectors of a track. Each 
block of data is linked with pointers to the next block of 
data and to the preceding block of data. Files are read and 
written by copying these blocks into and out of file buffer 
areas. A file buffer area is 278 bytes of memory. Whenever 
an FDOS routine performs a disk file operation such as 
reading or writing data, all access to the file is through a 
file buffer area. 
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PASS 5: Reading a Data File 


Pass 3 described a rote method for reading data into the 
computer from a disk file. With the file structure informa- 
tion from Pass 4, it is now possible to describe in detail the 
various methods of reading disk file data in from the disk. 
This chapter will show which FDOS routines are used and 
exactly what actual operations they perform to read in a 
linked data file from the disk. The chapter is divided into 
two subsections which concern preparing the file for input, 
and the actual input operations. 


Opening a File for Input 


The process of selecting which file on a disk is to be read 
in is known as opening the file for input, and every linked 
file to be read in to the computer must be opened for 
input. Any file which is being opened for input or read in 
must havea file buffer area (described in Pass 4) in memory. 
If more than one file is being read in, then there must be 
one file buffer area for each disk file being read in. 


REDFIL 


Example 3.3 described a method of reading a data file in 
from the disk, but there was no 278 byte file buffer area 
present as described in Pass 4. This is not a violation of the 
preceding paragraph, for there is a file buffer area used. The 
file buffer area is referred to as REDFIL and is the FDOS 
system input file buffer area. This is the file buffer used by 
FDOS to read programs in from the disk in order to run 
them. Once the program has been read in, there is no 
further need for this file buffer area, and it is available to 
users for inputting any file they may wish to read. The 
advantage of using this file buffer area for input is twofold: 
first, no memory area is required within the users program; 
second, it allows a convenient method of inputting the data 
byte by byte with the FDREAD routine described later in 
this chapter. 


Because the REDFIL file buffer area is part of FDOS, 
the position of REDFIL may vary from one version of 
FDOS to another. The address of REDFIL is always stored 
at a specific position, as a User Accessible Address (UAA) 
described in Appendix B. Executing the following instruc- 
tion will result in the HL register pair pointing to the first 
byte of the REDFIL file buffer area: 


LHLD —- FDOS+2AH 
Preparing the File Buffer Area for Input 


Opening a file for input consists essentially of specifying 
exactly which file on which disk drive you wish to read, 
and ascertaining that such a file does in fact exist. The 
file and disk to be read are specified by loading the first 
10 bytes of the file buffer area with the file name, exten- 
sion, and drive number as described in Pass 4. This file 
buffer area will then be associated with this disk file only 
during the opening and reading of the file. All references or 
accesses to this disk file will be made via this file buffer area. 

Example 5.1 shows a 278 byte block of memory 
which is set up as a file buffer area for the file named 
OTHELO.BAS residing on disk drive number 1 
(OTHELO.BAS:1). Note that the separators (. and :) are 


FBAIN: DB ‘OTHELOBAS' 
DB 


1 
DS 268 


Example 5.1: A 278 byte block of memory set up asa file 
buffer area for the file named OTHELO.BAS residing on 
the disk in drive number 1. 
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Table 5.1: Six examples of the action of the FILNAM 
routine. 


not included in the file name definition. The file name used 
is assumed to consist of a 6 letter file name and a 3 letter 
extension. By including a simple three line definition 
in an assembly language program, the user can define 
ahead of time which file on which disk is to be accessed. 

If one of several known files is to be read in by the 
program, then another method of preparing the file buffer 
area for input would be to have a list of the known files 
as shown in example 5.2. The user’s program would decide 
which of the five predefined files was to be read in, and 
then transfer the ten bytes from one of the locations 
FILE1, FILE2, FILE3, FILE4, or FILES into the ten 
bytes starting at FBAIN. After these ten bytes were trans- 
ferred, FBAIN would be ready to open the selected file 
for input. 


FILNAM 


Both of the preceding examples required the programmer 
to include the file names in the program when the program 
was written. This is very restrictive, especially if the user 


FILE1: DB ‘BACGAMMON’ ,O 
FILE2: DB ‘SPACE WAR’ ,O 
FILE3: DB ‘LIFE ‘0 


FILE4: DB ‘WUMPUS A 
FILES: DB ‘HANG MAN’ ,O 
FBAIN: DS 278 


Example 5.2: If one of several files can be read into a pro- 
gram, the method shown in this example can be used to set 
up an appropriate file buffer area. 


LX] H,FILASK 
CALL TXTYP 
FN1: CALL TXTIN 
FN2: LXI H,FBAIN 
FN3: CALL FILNAM 
Jc BADNAM 
JMP OPEN 
FILASK: DB ‘WHAT FILE?’,O 


FBAIN: DS 278 


Example 5.3: A typical use of the FILNAM User Accessible 
Routine to convert a stream of input text into a properly 
formatted file name specification. 


a_____::——_—_—_—_—_—_—_—___...._...._ 
—_—_—_—_—_—_————————— 


wishes to write a general purpose program such as an 
editor or an assembler, in which the file to be read in is not 
defined until the program is running. For this application 
there is a User Accessible Routine (UAR) titled FILNAM 
available to the user. The purpose of FILNAM is to convert 
a stream of text, typed in by the user, into a properly 
formatted file name specification stored in a file buffer 
area. A typical application is shown in example 5.3, which 
shows how the user should use FILNAM. The first two lines 
simply print out the prompt WHAT FILE? on the console 
device. Line FN1 calls TXTIN which allows the user to type 
in a line of text, in this case a file name (full details on 
TXTIN were given in Pass 3). After the user enters the 
file name and a carriage return, line FN2 loads the HL 
register pair with the address of FBAIN, the file buffer area 
of the input file. Calling FILNAM in line FN3 causes the 
FILNAM routine to put the file name entered by the user 
into the first ten bytes of FBAIN. 

FILNAM fills in any unused characters of the six letter 
file name or the three letter extension with blanks, and 
causes a default value of disk drive 0 if no drive is specified. 
Leading spaces and extra characters in the name or exten- 
sion are ignored, and the period and colon separators are 
removed. If FILNAM cannot find a valid file name in the 
TXTIN buffer, then FILNAM returns to the calling pro- 
gram with the carry flag set. If FILNAM successfully 
enters a file name into the area pointed to by HL, then 
upon return to the calling program the accumulator con- 
tains the ASCII value of the first character after the valid 
file name. FILNAM does not change the B, C, D, E, H, or 
L registers. 

Table 5.1 shows six examples of the action of the 
FILNAM routine. Example 4 demonstrates the fact that 
FILNAM will try to translate the first thing found in the 
TXTIN buffer. In this case, the REPLACE command is 
assumed to be a file on drive 0 titled REPLAC. If some 
initial characters in the TXTIN buffer are to be ignored, 
these must be passed over first by a series of calls to the 
TI routine. Examples 5 and 6 show illegally specified 
files, from which FILNAM will return with the carry 
bit set. 


Does Such a File Exist? (LOKFIL) 


Having properly set up the file buffer area to read a 
particular file in from the disk, we must make sure that 
this file does indeed exist on the disk. A file that does 
not exist certainly cannot be read in. To determine the 


existence of a file, the User Accessible Routine (UAR) 
LOKFIL is used. 


Example 5.4 demonstrates the proper use of the LOKFIL 
routine. First, the HL register pair is loaded with the 
address of the file buffer area which contains the file name, 
extension, and drive number of the file whose existence 
is in question. The LOKFIL routine is called and the 
directory of the specified disk is searched for the proper 
file name. If the file is not found, the carry bit is set, the 
DE register pair is set to zero, and LOKFIL returns to the 
calling program. If the carry bit is set on return from 
LOKFIL, any attempt to open the specified file will result 
in an error. 

If the file is found, the carry bit is reset (cleared). In this 
case, DE points to the first byte of a 16 byte block of 
memory in the FDOS buffer area (but not in the REDFIL 
or WRTFIL file buffer areas). This 16 byte block is a copy 
of the 16 byte directory entry for this file. Pass 8 fully 
describes the contents of this directory entry. Tne value 
of the DE register is normally ignored by the user, and only 
the carry bit need be examined to determine the existence 
or nonexistence of the file in question. 

Calling LOKFIL will not change the contents of the file 
buffer area, nor does LOKFIL use any but the first 10 bytes 
of the file buffer area to find the named file. LOKFIL does 
not change the B, C, H, or L registers. 


Opening the File for Input (OPNIN) 


Having properly specified the file and determined that 
it does exist, one more operation is required before the 
file can actually be read into the computer: the file must 
be opened for input using OPNIN. 

Example 5.5 demonstrates the proper way to open a file 
for input; simply load the HL register pair with the address 
of the file buffer area that is associated with this file and 
call OPNIN. OPNIN uses LOKFIL to obtain the 16 byte 
directory entry corresponding to the desired file. If no such 
entry is found, ERROR 04 occurs, indicating that no such 
file exists, and therefore the file cannot be opened for input. 

Assuming that the proper directory entry is found, 
OPNIN obtains the track and sector numbers of the first 
block of this linked file. These track and sector numbers 
are stored in the file buffer area bytes 14 and 15 (forward 
link) and the value 255 is stored in byte 20. OPNIN then 
returns with the carry bit cleared. Note that the first block 
of the linked file is now pointed to by the file buffer area, 
but the first block has not been read in yet. 


Opening a File for Input: Summary 


The steps performed in order to open a file for input 
are: 


1) File specification. 
2) Checking for file existence. 
3) Opening the file for input. 


In example 5.6, the file specification is performed during 
program assembly, when OTHELO.BAS:0 is assembled into 
the FBAIN file buffer area. Calling LOKFIL checks for file 
existence, and subsequently calling OPNIN opens the file 
for input. 

Example 5.7 uses a call to TXTIN to accept a file speci- 
fication from the console, followed by a call to FILNAM 
to properly format the file name into the file buffer area 
FBAIN. Note that the address of FBAIN is loaded into 


LXI H,FBAIN 
CALL LOKFIL 

Jc NOTFOUND 
JMP FOUNDIT 


Example 5.4: A demonstration of the proper use of the 
LOKFIL routine to test for the presence of a file on the 
disk. 


LXI H,FBAIN 
CALL OPNIN 
Jc NOSUCH 


Example 5.5: An example of the proper way to open a file 
using the OPNIN routine. 


LX! H,FBAIN 
CALL LOKFIL 

Jc NOTFOUND 
LXI H,FBAIN 
CALL OPNIN 


Jc NOTFOUND 


rest of program 


FBAIN: DB 


‘OTHELOBAS’ ,0 
DS 8 


Example 5.6: An example of the proper manner for open- 
ing the file “OTHELO.BAS:0” for input. 


CALL TXTIN 

LXI H,FBAIN 
CALL FILNAM 

JC BADNAM 
CALL LOKFIL 

JC NOTFOUND 
CALL OPNIN 


JC NOTFOUND 


rest of program 


FBAIN: DS — 278 


Example 5.7: An example of the proper manner for open- 
ing a file for input when the name of the file is input from 


the console. 


————————————————— 
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the HL register pair only once in this example. Because 
FILNAM, LOKFIL, and OPNIN do not change the contents 
of the HL register pair, there is no need to reload H and L: 
separately for each routine. HL will still contain the address 
of FBAIN after returning from the call to OPNIN. 

Example 5.8 is identical to Example 5.7 except that the 
FDOS system input file buffer area REDFIL is used. This 
reduces the users program size by 278 bytes. 

After performing any one of examples 5.6, 5.7, or 5.8, 
the selected file buffer area will be ready to actually read 
in the data. 


Input Operations 


This section will discuss three User Accessible Routines 
(UARs) which are used to read data in from the disk. 
These are BLKIN, BYTIN, and FDREAD. 


BLKIN 


The first call of BLKIN after an OPNIN will read in the 
first block of data from the selected disk file. Each succes- 
sive call to BLKIN brings in the next block of data from the 
linked file automatically. The block of data read in will be 
placed in the file buffer area. Only bytes 10 through 277 
inclusive will be copied from the disk file (see tables 4.1 
and 4.2) into the file buffer area; bytes 0 through 9 of the 
file buffer area are not changed. After these 268 bytes 
are copied, the current byte counter (byte 20 of the file 
buffer area) is set to zero. BLKIN is called with the HL 
register pair pointing to the file buffer area assigned to the 
desired file by the user’s call to OPNIN. The B, C, D, E, H, 
and L registers are not changed by BLKIN; and if the block 
of data is read in properly, the carry bit is cleared when 
BLKIN returns to the calling program. If FDOS detects 
any form of uncorrectable read error during the BLKIN 
disk data read, an error message will be displayed on the 
user’s console and BLKIN will return to the calling program 
with the carry bit set. The preceding paragraphs explain 
all of the actions of BLKIN which are visible to the user. 

BLKIN performs several functions which the user cannot 


CALL TXTIN: 
LHLD REDFIL 
CALL FILNAM 


Jc BADNAM 
CALL LOKFIL 
Jc NOTFOUND 


CALL OPNIN 
Jc NOTFOUND 


rest of program 


Example 5.8: Identical to example 5.7 except that the 
FDOS system input file buffer area REDFIL is used. 


ee ee 
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observe. BLKIN determines which disk block (track and — 
sector) to read from the forward link in the file buffer 
area. After this next block has been read in, but before the 
data is transferred into the file buffer area, BLKIN checks 
the reverse link of the block just read in and compares it 
to the current block as defined by bytes 10 and 11 of the 
file buffer area. This assures that the two supposedly 
linked blocks do indeed point to each other. If these 
numbers do not match, ERROR 07 is generated and the 
carry bit is set to indicate the error occurred. 

When BLKIN reads a block of data from the disk, the 
data is checked against the check sum bytes to make sure 
that the data was read in correctly. If these bytes do 
not agree with certain mathematical calculations, then 
the data must have been read in incorrectly. In this case 
ERROR 01 is flagged and the carry bit is set to indicate 
an error has occurred. 

When BLKIN is called and the last block of the linked 
file is read in, BLKIN should not be called again for this 
file (because there are no more blocks to be read). If 
BLKIN is called after the last block is read in, BLKIN 
indicates error 07 and no attempt is made to actually read 
a block of data. The user can detect the last block of data 
because it will have a zero forward link. The user should 
always check bytes 14 and 15 of the file buffer area before 
calling BLKIN. If these are both zero, the latest block 
read in was the last block of the file, and therefore no more 
blocks can be read in. BLKIN is frequently used when you 
wish to bring in large amounts of data all at once, rather 
than one byte at a time. 


BYTIN 


Whenever you wish to bring data in one byte at a time, 
as with most editors or assemblers, then the User Accessible 
Routine BYTIN is used instead of BLKIN. From the user’s 
point of view, BYTIN is quite simple to use: first, the HL 
register pair is loaded with the address of the file buffer 
area which was used to open the desired file; second, 
BYTIN is called. When BYTIN returns to the calling pro- 
gram, the next byte from the file being read is in the 
accumulator, and the carry bit is cleared. 


The first call to BYTIN after the file buffer area is used 
to open the file (with an OPNIN call) returns the first data 
byte from the file. The data bytes are those from byte 21 
to byte 276 on each disk block (see table 4.1). The first 
call to BYTIN will put byte 21 of the first block of the 
linked file into the Accumulator. The second call to BYTIN 
will put byte 22 into the Accumulator. The 257th call to 
BYTIN will put byte 21 of the second block of the linked 
file into the Accumulator, and so forth. 

After the last bvte has been read in by BYTIN, then the 
next call to BYTIN will return with zero in the Accumulator 
and the carry bit set. The setting of the carry bit signifies 
that the end of the file has been reached. BYTIN causes no 
change in the B, C, D, E, H, or L registers. The actions 
described above are the only actions of BYTIN which are 
visible to the user. 

BYTIN performs several actions which are invisible to 
the user. Each call to BYTIN first examines byte 20 of the 


file buffer area that HL points to. This is the current byte 
pointer; it tells which byte of the data area of this file 
buffer area is to be returned in the Accumulator. If byte 20 
is zero when BYTIN is called, byte 22 will be returned in 
the Accumulator. If byte 20 is 1, byte 23 will be returned, 
and if byte 20 is 254 byte 276 is returned. If byte 20 is 
255, then before returning a value, BYTIN calls BLKIN. 
BLKIN reads in the next block and then BYTIN returns 
byte 21 of the new block. Each call to BYTIN increments 
byte 20 by one count. 

When a file is opened, but before using BYTIN, OPNIN 
sets the file buffer area up with bytes 14 and 15 containing 
the track and sector of the first block of the file referred to 
by this file buffer area, and sets byte 20 to a value of 255. 
The first call to BYTIN after an OPNIN call for this file 
buffer area therefore causes BLKIN to be called and the 
first data byte of the first block is then returned in the 
Accumulator. 

During the byte-by-byte read of the last block of a 
linked file, byte 19 is used to count down the number of 
bytes available in the partially filled last block of data. 
When byte 19 reaches zero, the end of the file has been 
found, and the carry bit is set to indicate end of file. 

The user should note that 255 of every 256 calls to 
BYTIN will return to the calling program quickly (in much 
less than 1 millisecond), but once in every 256 calls, BYTIN 
will perform a BLKIN which could take up to 1 second 
under the worst conditions. Be careful, therefore, that no 
time critical processes are occuring during the execution of 
the BYTIN routine. Also, once every 256 calls, BYTIN will 
use on the order of 30 bytes of stack space, depending on 
your implementation of FDOS. 


FDREAD 


The FDREAD routine is exactly equivalent to exam- 
ple 5.9. The sole purpose of the FDREAD routine is to 
allow the programmer to use the B, C, D, E, H, and L 
registers with complete freedom, and to reduce the number 
of bytes required to read a data byte from the disk. None 
of these registers are changed by FDREAD, and the calling 
program may use them for any purpose. Note, however, 
that before using FDREAD for the first time OPNIN must 
be called, which will require the use of the HL register pair, 
as shown in example 5.8. 


The FDREAD features of register preservation and 
compact calling requirements make it ideal for patch- 
ing into existing software such as CLOAD in BASIC 
(example 3.5). 


Multiple Files 


All the examples in this chapter have described a situa- 
tion where the user program is reading data in from only 
one file on one disk. FDOS is actually much more flexible 
than this. While a file buffer area can only be used for one 
disk file at any one time, there is no limit (except for 
memory size) on the number of file buffer areas which can 


be present simultaneously. And each file buffer area may be 
reading a different file. Additionally, multiple file buffer 
areas may all be used to read the same file. One file buffer 
area can be halfway through a disk file while another file 
buffer area is just beginning or is nearly finished with the 
same file. 

Example 5.10 demonstrates how three files can be 
simultaneously open for input, and how the various read 
operations can be intermixed. All file names come from the 
console, so all files can be the same, or the files can have 
different names on the same or different disk drives. 
Briefly, the data operations performed in this example are: 


@ File 1 is opened for input and two blocks of data are 
read in. Nothing is done with the data. 

@ File 2 is opened, and the first and second bytes are read 
in and stored in CHR1 and CHR2. 

@ File 3 is opened via the system input buffer area 
REDFIL. 

@ A three instruction loop starting at LOOP is used to 
count the number of bytes read in from file 3 before the 
carry bit is set indicating end of file. The byte count for 
file 3 is then stored in LENGTH. 

@ The third byte of file 2 is read in and stored in CHR3. 

@ The third block of file 1 is read in, and again nothing is 
done with the data. 


While this program is of little practical use, it does 
demonstrate how several files can be opened and read in 
simultaneously by the various input routines BLKIN, 
BYTIN, and FDREAD. Note that you could also use 
BLKIN or BYTIN on the system input file buffer area 
REDFIL by performing a 


LHLD REDFIL 


instruction before calling BLKIN or BYTIN. 
“Rewinding” a File 


If you wish to use FDOS with a multiple-pass assembler 
or compiler, you will have to “rewind” the source file 
between successive compile or assemble passes. In FDOS, 
rewinding a file is accomplished by simply reopening the 
file. 

Example 5.11 reads a file from start to finish three 
times. After reading the file name in from the console, 
formatting the name in file buffer area FBAIN, and making 


2 ——————— 
lee 


PUSH H 

LHLD REDFIL equivalent to CALL FDREAD 
CALL BYTIN 

POP H 


Example 5.9: Implementation of the FDREAD routine. 
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sure that the file exists, the file is opened for input the 
first time. After LOOP1 reads the entire file once, the file 
is reopened. The HL register pair need not be reloaded, 
as the FILNAM, LOKFIL, OPNIN, and BYTIN routines 
did not change them. FILNAM need not be called again 
because the file name is already stored in FBAIN and has 
not been changed. LOKFIL is not needed, since we already 
know that the file exists from the last call to LOKFIL. 
Rewinding the file is accomplished simply by calling 
OPNIN again. This reopens the file at the beginning. 
After LOOP2 reads it a second time, the file is rewound 
again and LOOP3 reads it a third and final time. 


Reusing a File Buffer Area 


One final note: after you are finished with any file 
buffer area (including REDFIL), you can use it again for 
any other file (or the same file) simply by entering the 
new file name into the file buffer area and then using 
LOKFIL and OPNIN again, as described previously. No 
record is kept in FDOS of the status of the file buffer 
areas, so no action is required of the user to release a 
file buffer area for reuse. 


CALL = TXTIN 
LXI H,FBA1 
CALL FILNAM 
JC BADNAM 
CALL —_LOKFIL 
JC NOSUCH 
CALL __OPNIN 
CALL __BLKIN 
CALL __BLKIN 
CALL ~~‘ TXTIN 
LXI H,FBA2 
CALL FILNAM 
JC BADNAM 
CALL —_LOKFIL 
JC NOSUCH 
CALL —OPNIN 
CALL BYTIN 
STA CHR1 
CALL BYTIN 
STA CHR2 
CALL =‘ TXTIN 
LHLD ~—REDFIL 
CALL‘ FILNAM 
JC BADNAM 
CALL —_LOKFIL 
JC NOSUCH 
CALL _—OPNIN 
LXI H,0 
LOOP: CALL  FDREAD 
INX H 
JNC LOOP 
DCX H 
SHLD LENGTH 
LX! H,FBA2 
CALL BYTIN 
STA CHR3 
LX! H,FBA1 
CALL BLKIN 
HALT 
CHR1: DB 0 
CHR2: DB 0 
CHR3: DB 0 
LENGTH: DW 0 
FBA1: DS 278 
FBA2: DS 278 


;get the file name from the console 


;put the name into FBA1 

jexit if an illegal name 

jdoes the file exist? 

7no, quit! 

7yes, open for input 

;read in the first block 

;read in the second block 

;get a second file name from console 


;put the name into FBA2 
;does it exist? 


7yes, open for input 

;get the first character 
jstore in CHR1 

;get the second character 
;store in CHR2 

;get the third file name 

;use the system input buffer 
;store the third name here 


zis this a real file? 


7yes, Open it for input 

;set counter to 0 

;read a character 

;up the counter by 1 

;loop if not yet end of file 

;end of file found, fix count 

;store the number of bytes in LENGTH 
jset up file 2 

read in the third byte 

;store in CHR3 

;set up file 1 

;read in the third block 

;end of example 

:first character of file 1 goes here 
;second character of file 1 goes here 
;third character of file 1 goes here 
destination for length of file 3 

:file buffer area for file 1 

;file buffer area for file 2 


Example 5.10: How to open multiple files for input simul- 


taneously. 


Summary 


Pass 5 has described REDFIL, the system input file 
buffer area, and the User Accessible Routines FILNAM, 
LOKFIL, OPNIN, BLKIN, BYTIN, and FDREAD. FILNAM 
is used to properly format a name found in the TXTIN 
buffer into the file buffer area pointed to by the HL 
register pair. LOKFIL searches the directory of the selected 
disk for the file name specified in the file buffer area 
pointed to by the HL register pair, and clears or sets the 
carry bit if the file does or does not exist, respectively. 
OPNIN sets up the file buffer area pointed to by HL in 
preparation for BLKIN, BYTIN, or FDREAD. BLKIN 


brings in one block of the desired file each time it is called, 
and the block of data is stored in the file buffer area 
pointed to by HL. BYTIN brings in one byte of the desired 
file each time it is called, and the data byte is returned in 
the Accumulator. BYTIN uses the file buffer area pointed 
to by HL to buffer the incoming blocks of data. FDREAD 
is the same as BYTIN, but always uses REDFIL for a buffer 
and does not use or change the HL register pair. 

Multiple files can be opened simultaneously for input, 
providing that there is one file buffer area for each file 
being read. Files can be reread by reopening them, which 
starts them at the beginning again. Finally, any time that a 
program is finished with any input file, the file buffer area 
that was used for reading that file can be used for another 
file, or can be used by the program for any other purpose. 


CALL = TXTIN 
LXI H,FBAIN 
CALL FILNAM 
JC BADNAM 
CALL LOKFIL 
JC NOSUCH 
CALL _—OPNIN 
LOOP1: CALL BYTIN 
JNC LOOP1 
CALL —OPNIN 
LooP2: CALL BYTIN 
JNC LOOP2 
CALL OPNIN 
LOoP3: CALL 
JNC 
HALT 
FBAIN: DS 


;get the file name from the console 
;only once, store it in FBAIN 

;and never change HL 

;jump if the name is bad 

;does the file exist? 

;nope, abort 

yyes, open it for input 

jread a byte, simulate pass 1 


jloop through the entire file 


sno need to reload HL 
sno need to do FILNAM again 
jno need to do LOKFIL again 


jsimulate pass 2 ; 
sloop through same file again 


srewind again, for pass 3 


BYTIN sloop through again 
LOOP3 ;simulate pass 3 

;end of example 
278 


Example 5.11: How to rewind a file by reopening it. 
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PASS 6: Writing a Data File 


Pass 5 contained detailed descriptions of the various 
methods of reading data from a linked data file on a disk. 
This chapter complements Pass 5, describing in detail the 
requirements and methods of writing a linked data file 
onto the disk. Writing a file, like reading a file, requires 
that the programmer open the file and then transfer the 
desired data. Unlike reading a file, the user must perform 
a file close operation after writing a file. This chapter 
covers this information in three sections: how to open the 
file for output; how to put data out to the disk; and how to 
close the output file. 


Opening a File for Output 


The process of creating a file on the disk for the storage 
of data is known as opening a file for output. Any time 
that you wish to write data to a linked disk file you must 
first open that file for output, and to do this the user 
must have a file buffer area in memory. This file buffer 
area will be associated with the output file during opening, 
data writing, and closing. 


WRTFIL 


Example 3.4 listed a program that wrote a linked data 
file to the disk, but there was no 278 byte file buffer 
area present in the listing, as specified by the above para- 
graph. The file buffer area used in example 3.4 is WRTFIL, 
the FDOS system output file buffer area. This is the file 
buffer area used by FDOS to store programs on the disk 
during a SAVE command. Since this area is’ used only 
during the save command, WRTFIL can be used by a user’s 
program to write data on the disk during execution of the 
user’s program. As with the REDFIL system file buffer 
area, the advantages of using WRTFIL for writing a file are 
twofold: First, no file buffer area is needed within the 
user’s program (a savings of 278 bytes); and second, this 
allows a simple and convenient method of writing data 
to the disk one byte at a time, as described in the FOWRT 
section later in this chapter. 

Because the WRTFIL file buffer area is part of FDOS 
(like REDFIL), the position of WRTFIL will vary from one 


version of FDOS to another. The address of WRTFIL is 
always stored at a specified location within FDOS. 
WRTFIL is a User Accessible Address (UAA) as described 
in Appendix B. Performing an 


LHLD FDOS+2CH 
or 

LHLD WRTFiL (where WRTFIL=FDOS+2CH) 

instruction will result in loading the HL register pair with 

the address of the first byte of the 278 byte FDOS system 

output file buffer area. 


Preparing the File Buffer Area for Output 


Before a file buffer area can be used to open a file for 
output, the file specification (file name, extension, and 
drive number) must be stored in the file buffer area in the 
proper format. The requirements and methods for doing 
this are exactly the same as the requirements and methods 
for entering a file specification in the file buffer area of 
an input file. These will be summarized briefly, but the 
reader desiring more detail is referred to the section in 
Pass 5 titled Preparing the File Buffer Area for Input. 

There are three main methods of file name entry in 
output file buffer areas, as shown in examples 6.1, 6.2, 
and 6.3. 

Example 6.1 shows a 278 byte block of memory 
set up as a file buffer area to write out a file named 
DATA.OUT:1. Comparing example 5.1 to example 6.1 
shows that there is no difference in the structure of the 
file buffer areas for either input or output at this stage. 


FBAOUT: DB ‘DATA OUT' ,1 
DS 268 


Example 6.1: A 278 byte block of memory set up asa file 
buffer area for the output file DATA.OUT:1. 
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In example 6.2, the users program might be calculating 
some data values from formulae that use different radius 
values. Depending on the radius values used, the program 
would copy ten bytes from location FILE1, FILE2, FILE3, 
or FILE4 into the first ten bytes of FBAOUT. After these 
ten bytes were copied, FBAOUT would be ready to use for 
opening the selected file for output. 

Finally, the FILNAM routine in FDOS can be used 
to allow the programmer to enter the file name, extension, 
and drive number from the console at run time. 

Example 6.3 demonstrates how FILNAM is used to take 
a name from the console and store it in the output file 
buffer in the proper format. Note that example 6.3 is 
nearly identical to example 5.3. FILNAM is used identically 


FILE1: DB ‘RADIUS037’ ,O 
FILE2: DB ‘RADIUS049’ ,O 
FILE3: DB ‘RADIUS062’ ,O 
FILE4: DB ‘RADIUSO75S’ ,O 
FBAOUT: DS 


Example 6.2: See text for an explanation of this example. 


LXI H,FILASK 
CALL TXTYP 
CALL TXTIN 

LXI H,FBAOUT 
CALL FILNAM 


Jc BADNAM 


rest of the program 


FILASK: DB ‘WHAT FILE?’ ,’ ‘+128 
FBAOUT: DB 278 


Example 6.3: Here, the FILNAM routine is used to allow 
the user to enter the file name, extension, and drive number 
from the console at execution time. 


LX! H,FBAOUT 
CALL LOKFIL 
JNC EXISTS 


;set HL to the output FBA 
;check the file existence 
;ERROR, branch if it already exists 


rest of the program 


Example 6.4: A demonstration of the LOKFIL routine. 


LXI H,FBAOUT 
CALL OPNOT 
Jc EXISTS 


;set HL to the output FBA 
stry to create the file 
:file already exists, quit 


rest of the program 


Example 6.5: The OPNOT routine is used to create a file, 
opening the file for output. 
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with either input or output file buffer areas, because 
file specifications are stored identically in either input or 
output file buffer areas. For full details on the operation 
of FILNAM, refer to Pass 5 section FILNAM. 


Use of LOKFIL with Output Files 


When opening a file for output, FDOS is actually creat- 
ing a file with the specified name to hold the data you 
wish to write. Since a file with this name is being created, 
it is necessary that no file with the same name already 
exist on the disk. If FDOS were allowed to create a second 
file with the same name on the same disk, then there 
would be no way to know which file you were reading 
when you tried to read the file back later. 

Before actually creating the file, then, you must ascer- 
tain that no file of the same name already exists on the 
selected disk. Pass 5 described a routine LOKFIL which 
checks for the presence or absence of any particular file 
on a disk. 

Example 6.4 demonstrates the use of the LOKFIL 
routine. The HL register pair is loaded with the address 
of the file buffer area which contains the name of the 
file to be created. LOKFIL is called and when LOKFIL 
returns, the carry bit is examined. If the carry bit is not 
set, LOKFIL found a file by this name on this disk. If the 
file already exists, then it cannot be opened for output 
(created), and example 6.4 jumps to an error routine 
labeled EXISTS. If LOKFIL sets the carry bit, then no such 
file exists yet and it is legal to open this file for output. 

LOKFIL and FILNAM have been described in this 
chapter as they are applied to output files, and they were 
described in the previous chapter as they were applied to 
input files. Both of these routines are used identically 
with either input or output files, and it should be noted 
that neither LOKFIL nor FILNAM makes any distinction 
between input and output files. These are the only routines 
in this chapter that are independent of file input or output. 
The rest of the routines described in this chapter are output 
routines that (with the exception of CLSOT) are exact 
analogs in function and use of the input routines described 
in Pass 5. 


Opening the File for Output (OPNOT) 


Opening the file for output can also be thought of as 
creating an output file, for that is the function that OPNOT 
performs. After it has been determined by LOKFIL that 
no file currently exists with the specified name, OPNOT 
is used to create this file, thereby opening the file for 
output. Example 6.5 demonstrates the proper way to open 
a file for output. Load the HL register pair with the address 
of the file buffer area that is to be used for this file, and 
then call OPNOT. Before creating the file, OPNOT uses 
LOKFIL to make sure that another file by this name does 
not exist. If a duplicate does exist, OPNOT signals ERROR 
03 and the carry bit is set on return from OPNOT to 
indicate that the file cannot be opened for output. 


If OPNOT determines that no such file exists, OPNOT 


will create a file with this name. First, FDOS finds a data 
block on the disk that is not used by any existing file. 
FDOS makes this block the first block of the linked data 
file being created. OPNOT then enters the file name, the 
date, and the pointer to the first block of this file into 
the directory. OPNOT also puts the current date and a 
file length of zero in the directory and then rewrites the 
modified directory onto the disk. The file buffer area 
is loaded with the track and sector number of the first 
block in bytes 10 and 11, and a reverse link of 0, 0 (indi- 
cating that this is the first block of the file) in bytes 12 and 
13. Bytes 14 and 15 of the file buffer area (the forward 
link) are not filled at this time, since it is not yet known 
what the next block will be, or even whether there will be 
another block. Byte 20 (data byte count) of the file buffer 
area is loaded with the value 255, signifying that no data 
is yet stored in the block. After performing all of these 
functions, OPNOT returns to the calling program with the 
carry bit cleared. OPNOT does not change the B, C, D, 
E, H, or L registers. 


Opening a File for Output, Summary 


To open a file for output, the user must perform three 
steps: 


1) File specification: Assemble the file name into the file 
buffer area or enter it via FILNAM. 

2) Check file existence: Call LOKFIL and make sure the 
carry is set upon return, indicating file does not exist 
already. 

3) Open the file for output: Call OPNOT which creates 
the file in the directory and reserves the first block on 
the disk for the file. 


Example 6.6 shows the simplest way to open a file for 
output. The file buffer area to be used for the output is 
assembled with the file specification already present in 
FBAOUT (TEST.DAT:2). The user calls LOKFIL to 
make sure that no file named TEST.DAT already exists 
on disk 2. If such a file does exist, control goes to the pro- 
gram section labeled EXISTS (not shown here). If no such 
file exists, then OPNOT is immediately called (the HL 
register pair still contains the address of the file buffer 
area, FBAOUT). A file called TEST.DAT:2 is created 
and the program continues. 

In example 6.7, the user enters the output file name 
on the console, and the FDOS system output file buffer 
area WRTFIL is used for output. FILNAM formats the 
file name from the TXTIN buffer to the WRTFIL file 
buffer area. LOKFIL makes sure that the file does not 
already exist, and then OPNOT is used to create the file. 
Note that the HL register pair is loaded once at the start 
of example 6.7. At the end of the code shown, H and L 
will still contain the address of the WRTFIL file buffer 
area. Also notice that the user need not supply the file 
buffer area, thereby reducing the program size by 278 
bytes. 


After performing the code in either of these two 
examples, a file of the specified name is created. However, 
at this time it is not yet a valid file, and any attempt to 
read this file before all the data has been written and the 


file has been closed will result in erroneous data being 
read. 


Output Operations 


In normal use, data is written to the linked disk files 
by one of three User Accessible Routines in FDOS: 
BLKOT, BYTOT, or FDWRT. Recalling or re-examining 
the Input Operations section of Pass 5 will show that all 
linked file input under FDOS was performed by BLKIN, 
BYTIN, and FDREAD. This may give the reader a slight 
inkling of what lies ahead. BLKOT, BYTOT, and FDWRT 
are the exact output counterparts to these previously 
described input routines. 


BLKOT 


Each call to BLKOT will add one block of data to the 
end of the linked file on the disk. In essence, calling 
BLKOT copies the entire file buffer area out to a disk 
block which is linked to the current end of the file. Before 
calling BLKOT, the user should put all of the data to be 
written on the disk into the data portion of the file buffer 


LXI H,FBAOUT 
CALL LOKFIL 
JNC EXISTS 
CALL OPNOT 


Jc ERROR 


rest of the program 


FBAOUT: DB ‘TEST DAT’ ,2 
DS 268 


Example 6.6: The simplest way to open a file for output. 


CALL TXTIN 
LHLD WRTFIL 
CALL FILNAM 
JC BADNAM 
CALL LOKFIL 
JNC EXISTS 
CALL OPNOT 


JC ERROR 


rest of the program 


Example 6.7: A setup which allows the user to enter a file 
name from the console, opening that file for output. Note 
that the WRTFIL file buffer area is used. 
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area (bytes 21 through 276). Caution: the user must not 
change any of bytes 0 through 15 of the file buffer area. 
If BLKOT (or BYTOT or FDWRT) is called after changing 
these bytes, incorrect data will be recorded. At best you 
will be unable to read your file, and at worst you will 
destroy data written on this file or some other file, or even 
some other disk! 

The proper use of BLKOT is shown in example 6.8. 
First the data to be stored is moved from the memory 
at TABLE to the data area of FBAOUT, bytes 21 through 
276. The HL register pair is loaded with the address of the 
file buffer area to write (FBAOUT), and BLKOT is called. 

When BLKOT is called, FDOS determines the next 
available disk block, the next block of disk space which 
is not currently part of an existing file. This new block is 
declared to be attached to this file, and therefore unavail- 
able to any other file currently or subsequently being 
written. This new block will follow the current block of 
data that BLKOT is in the process of recording on the disk. 
BLKOT loads the track and sector of this new disk block 
into the forward link (bytes 14 and 15) of the file buffer 
area. The data stored in the file buffer area locations 0 
through 277 is used to calculate the error detection bytes 
that will be recorded on the disk. 

BLKOT now writes the entire file buffer area, complete 
with forward link and error detection bytes, onto the 
disk. The block that this data is written to is determined 
by bytes 9 (disk drive number), 10 (track), and 11 (sector) 
of the file buffer area. In the preceding section describing 
the operation of OPNOT, it was stated that OPNOT finds 
the first available (free) block on this disk and stores the 
track and sector of the block in file buffer area bytes 10 
and 11. Therefore the first call to BLKOT after the file is 
opened for output will store the block of data on the disk 
block pointed to by the directory entry for this file. After 
the block of data is written, BLKOT moves the current 
block pointer (bytes 10 and 11) into the reverse link 


(bytes 12 and 13), and then moves the forward link (bytes — 
14 and 15, just filled) to the current block pointer (bytes 
10 and 11). It can be seen, then, that several successive 
calls to BLKOT will write a series of linked blocks of data 
onto the disk, with each block containing a pointer to the 
preceding and the following blocks of data. This is the 
manner in which FDOS creates all linked files. 

Between successive BLKOT operations, the user’s file 
buffer area is used to store the information about where 
this block of data is to be stored on the disk and where 
the previous block of data was stored. These vital data 
are the reason for the caution about not changing any of 
the data bytes from 0 through 15. The fact that FDOS 
automatically selects the next free block on the disk is 
a mixed advantage to the user. It completely relieves 
the user from having to predetermine file size or location, 
but it gives the user no control over where the data is 
stored on the disk. This mode of operation was written 
into FDOS because it is the most convenient, and FDOS 
places a higher premium on convenience than on efficiency. 

Every time BLKOT is called, one block of data is written 
on the disk and one more block is reserved for later linking 
to the file. Because of this feature, the user should not use 
BLKOT to put out the last block of data in a linked file, 
as this will attach an extra, unwanted block containing 
no data (the block reserved by the last BLKOT operation) 
to the file. When using BLKOT, substitute a call to CLSOT 
for the BLKOT call that would otherwise put out the 
last block of data. The operation of CLSOT will be de- 
scribed later in this chapter. 

BLKOT does not modify the A, B, C, D, E, H, or L 
registers. 


BYTOT 


Most microprocessor applications which generate data 
to be stored operate on that data one byte at a time. Most 
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LXI H,TABLE point to data to be stored 
LXI D,FBAOUT+21 ;point to FBA data area 
MVI B,256 ;move a full 256 bytes 
LOOP: MOV A.M 
STAX D 
INX H 
INX D 
DCR B 
JNZ LOOP sloop until all 256 bytes are moved 
LX! H,FBAOUT ;point to the file buffer area 


CALL BLKOT 


rest of the program 


TABLE: DS ~° 256 


FBAOUT: DS 278 


; area Containing the data to move 


;Output file buffer area 


Example 6.8: An example of the proper use of the BLKOT 
routine to add one block of data to the end of a linked file 


on the disk, 
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existing editors, assemblers, and compilers generate a 
stream of data in a byte-by-byte fashion whether the data 
to be stored is text, listings, or object code. The User 
Accessible Routine BYTOT is designed specifically for 
these applications. 

The correct format for using BYTOT is shown in 
example 6.9. Before BYTOT is called for the first time, 
the output file must be opened for output with a call 
to the OPNOT routine described earlier. After the file 
has been opened for output, the address of the file buffer 
area used for the OPNOT routine is loaded into the HL 
register pair, and the byte of data to be stored is loaded 
into the C register. A call is then made to BYTOT and the 
data is properly stored for transfer to the disk file. Notice 
that BYTOT is quite similar to the console (CO), punch 
(PO), and list (LO) output routines. All of these routines 
expect the byte of data for output to reside in the C 
register, and all of these routines accept only one byte 
of data per call. This similarity between the disk output 
routines and the other device output routines is quite 
deliberate. The purpose is to enable the user to store 
data on the disk as easily as on paper tape or on a list 
device. BYTOT does not modify the B, C, D, E, H, or L 
registers. 


To the user, the BYTOT routine appears nearly identical 
to a paper tape punch routine. Instead of punching a 
paper tape leader, the user must open the file for output. 
Then all of the data to be stored is sent to the output 
device one byte at a time. After all of the data to be stored 
has been sent, the user closes the output file on disk instead 
of punching a paper tape trailer on tape (more will be said 
about closing an output file shortly). All the user sees of 
the BYTOT routine, then, is a simple routine to send data 
to the disk one byte at a time. 

What the user does not see (intentionally) is the fact 
that one cannot write a single byte of data at a time to 
a disk drive, at least not in any currently practical appli- 
cation. The BYTOT routine performs an invisible buffer- 
ing task called data blocking. Data blocking is simply the 
collection of data (in this case collecting it one byte at a 
time from the BYTOT routine) until enough data exists 
(256 bytes) to write one block of data to the disk. BYTOT 
uses the file buffer area pointed to by the HL register 
pair to perform this buffering operation. 

Upon entry, BYTOT increments the value stored in byte 
20 of the file buffer area. This value points to one of 
the data bytes in the data area of the file buffer area. 
If byte 20 is zero, the byte pointed to is byte 21. If byte 20 
is one, then byte 22 is pointed to, and so forth until a value 
of 255 in byte 20 points to data byte 276 of the file 
buffer area. The data in register C is stored in the data byte 
pointed to by byte 20, and byte 20 is incremented by one. 
If a data byte is stored into data byte 276 of the file 
buffer area (filling the data section), then the call to 
BYTOT fills the buffer area, and BYTOT performs a call 
of BLKOT. On the first call of the BYTOT routine after 
opening a file for output (or after a previous BYTOT 
operation caused the BLKOT routine to be called), the file 
buffer area is considered empty and the contents of the C 
register will be stored in file buffer area byte 21, the first 


of the 256 data bytes. Each successive call to BYTOT 
stores the C register in the next byte until all 256 data 
bytes are filled and BLKOT is called. 

The user should note that for 255 of every 256 calls 
to BYTOT, control will return to the calling program in 
less than 100 microseconds. Once every 256 calls to 
BYTOT, however, BLKOT will be called and it may require 
up to one second under the worst conditions before 
BYTOT returns to the calling program. Be careful that no 
time critical processes are occurring during the calls to 
BYTOT. The one call of BYTOT that in turn calls BLKOT 
will also require about 30 bytes of stack space (depending 
on your version of FDOS), so make sure that this much 
stack space is available before calling BYTOT. 


FDWRT 


The FDWRT routine is exactly equivalent to example 
6.10. 

Since FDWRT uses the system output file buffer area 
WRTFIL for output, the user does not need a 278 byte area 
of his or her program reserved for the file buffer area. In 
addition, the FDWRT routine does not modify the B, C, D, 
E, H, or L registers and it allows the user to store any values 
desired in the HL register pair. This makes FDWRT an 
exact functional equivalent of the CO, PO, or LO routines. 
Note, however, that before using FDWRT the first time, 
the file must be opened for output with a call to OPNOT, 


LXI H,FBAOUT 
MVI C,data 
BYTOT 


CALL 


rest of the program 


Example 6.9: The correct format for using the BYTOT rou- 
tine to store data internally for transfer to the disk. 


PUSH H 
LHLD WRTFIL 


FDWRT 
CALL BYTOT 
H 


——equivalent to—-— CALL 


Example 6.10: The FDWRT User Accessible Routine. 


LXI H,FBAOUT 
CALL CLSOT 


rest of the program 
FBAOUT: DS —s278 


Example 6.11: The proper format for calling the CLSOT 
routine to close a file. 
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and after the last call to FDWRT the file must be closed. 

The FDWRT features of register preservation and com- 
pact calling requirements make FDWRT ideal for patching 
into existing software, such as the CSAVE command in 
BASIC (example 3.5). FDWRT and FDREAD together 
make it quite easy to adapt existing software to utilize 
the full powers of FDOS, even if the user is not able to 
reassemble the programs that are being patched. 


Closing an Output File (CLSOT) 


After the last call to BLKOT, BYTOT, or FDWRT the 
output file is not yet complete. If BYTOT or FDWRT 
routines were used to send data to this disk file, then there 
is usually some data in the file buffer area that is not yet 
on the disk. Unless an exact multiple of 256 bytes was out- 
put to the disk file via the BYTOT or FDWRT routines, 
some fraction of a full block of data is stored in the file 
buffer area and not on the disk. Calling the CLSOT routine 
will write this last block of data onto the disk in the proper 
format as shown in example 6.11. First, the HL register 
pair is loaded with the address of the file buffer area being 
written on the disk, and then CLSOT is called. CLSOT does 
not modify the B, C, D, E, H, or L registers. 

In addition to putting the last partial block of data onto 


the disk, CLSOT performs several vital housekeeping 
functions. CLSOT sets the forward link (bytes 14 and 15) 
of the last block to zero, indicating that this block is the 
last block of this file on the disk. Byte 19 is loaded with 
the partial byte count to show how many valid bytes are 
actually stored in this block of data. The last block of 
data, with these amendments, is then written on the disk. 
CLSOT marks all of the blocks used by this linked file 
as being occupied, so that no other output file will attempt 
to use the same blocks. Finally, CLSOT records the length 
of this file in blocks (multiples of 256 bytes) in the disk 
directory entry for this file. 

In the special case that the BLKOT routine is being used 
to write a data file, CLSOT should be used instead of 
the last call to BLKOT. In this instance, CLSOT acts just 
like a call to BLKOT, except that a forward link of zero is 
recorded to indicate that the block being written is the last 
block of the file. As before, CLSOT will also mark all of 
the blocks in the file as occupied and the directory byte 
count will be updated. 

It can be seen from this description of the CLSOT func- 
tions that failure to call CLSOT at the end of a file write 
operation can lead to the loss of some or all of the data in 
the disk file. Make sure that programs which write disk 
data files always close these output files properly. For this 


CALL TXTIN 
LXI H,FBAOUT 
CALL FILNAM 
JC BADNAM 
CALL LOKFIL 
JNC EXISTS 
CALL OPNOT 
CALL BLKOT 
CALL BLKOT 
CALL TXTIN 
LHLD WRTFIL 
CALL FILNAM 
JC ERROR 
CALL LOKFIL 
JNC ERROR 
CALL OPNOT 
MVI C,1 
LXI H,FBAOUT 
LOOP: CALL FDWRT 
INR Cc 
JNZ LOOP 
CALL BLKOT 
MVI C,13 
CALL FDWRT 
MVI C,10 
CALL FDWRT 
CALL CLSOT 
LHLD WRTFIL 
MVI Cc,0 
CALL BYTOT 
CALL CLSOT 
end of the program 
FBAOUT: DS 278 


iget the file name from the console 


;put the name in FRAOUT 
;exit if an illegal name entered 
;does the file exist? 

7yes, error routine 

;no, create it for output 

;put out the first block 

;put out the second block 

;get a second file name 

;use system out file buffer area 
;put the name in WRTFIL 
;illegal name branch 

;does the file exist? 

yes, error exit 

;no, create the second file 


;HL points to first file 

;but we write to the second file 
;255 successive integers 

suntil C=O 

;put out the third block, first file 
;send second file a <cr> 


;send second file a <1f> 


;close the first file 

;FBA of second file 

send second file a final 0 
;note this BY TOT=FDWRT 
:close the second file 


;file buffer area of first file 


Example 6.12: A demonstration of opening multiple files 


simultaneously for output. 


reason it is important that you never remove a floppy disk 
from a disk drive while an output file is still opened for 
output on that disk! 


Multiple Files 


As with the various input routines described in Pass 5, it 
is permissible to have any number of output files open 
simultaneously. The only requirement is that each file 
must have its own file buffer area. In fact, different files 
can be open for both input and output at the same time. 
The only restriction on the total number of files is that 
each file open for input or output has to have its own file 
buffer area. The limiting factor thus becomes the amount 
of available memory. 

Example 6.12 demonstrates how two different output 
files can be simultaneously open for output. A brief de- 
scription follows: 


1) The file name of the first file is read in from the con- 
sole, and the file is opened for output. 

2) Two blocks of (dummy) data are written to the first 
file with the BLKOT routine. 

3) The file name of the second file is read from the 
console and the file is opened for output. Note that if 
either a bad name or an already existing name is used, 


the error exit is labeled ERROR. The routine at 
ERROR must take into account the fact that the first 
file is already opened for output and should be closed 
before the program can be aborted. 

4) The HL register pair is loaded with a pointer to the 
first file buffer area. 

5) 255 successive integers are sent to the second file 
without using the HL register pair, which still points 
at the file buffer area of the first file. 

6) A third dummy block is written to the first output 
file. 

7) A<cr>,<1f> is sent to the second output file. 

8) A fourth and last dummy block is written to the first 
output file as it is closed and the directory is updated. 

9) The HL register pair is loaded with the address of the 
rai file buffer area (the system output file buffer 
area). 

10) A zero byte is written in the second file using the 
BYTOT routine. 

11) The second file is closed, the partial data block is 
recorded on disk and the directory is updated. 


This example serves no practical purpose except to 
demonstrate various legal uses of the routines covered 
in this chapter. If any of the uses shown in example 6.12 
seem unusual or illegal, reread the appropriate section 
of this chapter for a better understanding of the routine. 
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Example 6.13: How to merge two input files and create 
two identical output files, each containing the merged input 


files, 


ASKNAM: DB 
DB 


START: LXI H,ASKNAM 
CALL TXTYP 
CALL TXTIN 
LXI H,FBI1 
CALL NAMGET 
JC ERROR 
CALL OPNIN 
LXI H,FBI2 
CALL NAMGET 
JC ERROR 
CALL OPNIN 
LX! H,FBO1 
CALL NAMGET 
JNC ERROR 
LXI H,FBO2 
CALL NAMGET 
JNC ERROR 
CALL OPNOT 
LXI H,FBO1 
CALL OPNOT 
CALL READ1 
CALL READ2 

: CALL COMPAR 
sea JM TWoBIG 


‘ENTER 2 INPUT, 2 OUTPUT NAMES’, 13,10 
‘SEPARATED BY COMMAS’, 13,10,0 


;request 4 names from the user 
jread in the names 

:file buffer area of first input file 
;get the name and existence 

sif nonexistent, quit 

;if present, open for input 

sdo the same for input file 2 


jopen input file 2 


sthird name is first output file 


sif already present, quit : 
;fourth name is second output file 


sif already present, quit 


;open FBO2 for output 


jopen FBO1 for output 
sget 32 bytes of file 1 
sget 32 bytes of file 2 


scompare customer names _ 
sjump if file 1 comes before file 2 
sin alphabetic order 


41 


42 


ONEBIG: 


LOOP2: 


TWOBIG: 


LOOP3: 


EOBOTH: 


NAMGET: 


READ1: 


LOOP4: 


READ2: 


WRIT1: 
LOOP6: 


WRIT2: 


COMPAR: 


CALL WRIT2 jwrite entry from file 2 


CALL READ2 srefill entry from file 2 

JNC LOOP1 jloop if file 2 not yet empty 
CALL WRIT1 ;file 2 is done, finish off file 1 
CALL READ1 

JNC LOOP2 jloop until file 1 empty 

JMP EOBOTH ;end of both 

CALL WRIT1 jwrite entry from file 1 

CALL READ1 jread new entry from file 1 

JNC LOOP1 jloop if file 1 not yet empty 
CALL WRIT2 ;file 1 is done, finish off file 2 
CALL READ2 

JNC LOOP3 ;loop until file 2 empty 

LXI H,FBO1 ;close both output files 

CALL CLSOT 

LXI H,FBO2 

CALL CLSOT 

HALT send of the program 

CALL FILNAM 3get the next file name from TXTIN 
JC ERROR if any name is bad, then quit 
CALL LOKFIL else check if the name exists 
RET ;return with carry telling existence 
LXI H,FBI1 ;read in 32 bytes from file 1 

LX! D,BUF1 ;into the first entry buffer 

MVI B,32 

CALL BYTIN ;get one byte of datain A 

RC ;early return if End Of File 
STAX D ;store the data byte 

INX D ;up the counter 

DCR B 

JNZ LOOP4 juntil 32 characters are moved 
RET ;then return 

(similar to READ1) 

LX! D,BUF1 jwrite 32 bytes from the first entry 
MVI B,32 ;buffer 

LDAX D ;get the byte 

MOV Cc ;put into C for BYTOT 

LXI H,FBO1 ;put byte out to first output file 
CALL BYTOT 

LX! H,FBO2 ;then to second output file 
CALL BYTOT 

INX D ;up the pointer 

DCR B ;down the counter 

JNZ LOOP6 until all 32 bytes out to both files 
RET ;then return to calling program 
(similar to WRIT1) 


(this routine compares the names and returns with §S set if the 
second entry comes before the first entry alphabetically) 


HALT ;some error occurred 

DS 278 :first input file buffer area 

DS 278 ;second input file buffer area 
DS 278 ;first output file buffer area 
DS 278 ;second output file buffer area 
DS 32 :first entry buffer area 

DS 32 ;second entry buffer area 


ed 


Simultaneous Multiple Input and Output 


Example 6.13 is a program to merge two input files and 
create two identical output files, each containing the 
merged input files. The two input files are assumed to each 
consist of at least one entry, and all entries within each 
file are in alphabetical order. Each entry is 32 bytes long 
and could contain, for example, a customer name and 
credit balance. In this case the program would merge the 
update file into the reference file to keep the customer 
list current. 

There are several instructive features in example 6.13 
which are briefly described here. The four file names are 
all typed in at one time by the user. The FILNAM routine 
reads a file name from the TXTIN buffer one character at a 
time via the TI routine. When FILNAM finds a comma 
separating two successive file names in the TXTIN buffer, 
FILNAM stops and returns to the user’s program. The next 
call to FILNAM will look for the next file name starting 
with the first character after the comma. In this manner 
FILNAM (embedded in the NAMGET subroutine in this 
example) will read four file names into the file buffer 
areas FBI1, FBI2, FBO1, and FBO2 from one TXTIN 
buffer. 

Another point to notice is that the input files are opened 
immediately upon ascertaining (by LOKFIL in NAMGET) 
that they exist. But neither of the two output files is 
opened until it is determined that neither output file name 
already exists, and both input files are properly opened. 
This assures the user that both output files can be opened 
and that no special cases of closing only one file or the 
other will have to be performed. 

The sorting method starts by putting one customer 
entry from each input file into an intermediate buffer 
area (BUF1 and BUF2). The sorting loop now uses the 
COMPAR routine to find out if the entry from file 1 comes 
before or after the entry from file 2. The entry buffer 
which is alphabetically first is written out to both output 
files, and that buffer is refilled from the corresponding 
input file. As soon as either input file is exhausted, the 
rest of the other input file is written until completed 
and both output files are closed (at EOBOTH). This com- 
pletes the data merge. 

The only reason for using two output files in this ex- 
ample is to demonstrate that multiple input operations 
can be mixed with multiple output operations. A more 


practical example would exceed the intent of this book 
and probably the patience of the reader. 


Reusing a File Buffer Area 


As with input files, the file buffer areas used to output 
files can be reused after the output file is complete. How- 
ever, make very sure that the output file has been closed 
with the CLSOT routine before using the file buffer area 
for any other purpose. Failure to heed this warning may 
destroy any or all of your disk data. 


Summary 


This chapter has described WRTFIL, the system output 
file buffer area and how the User Accessible Routines 
FILNAM, LOKFIL, OPNOT, BLKOT, BYTOT, FDWRT, 
and CLSOT are used to write files onto the disk. All of 
these except CLSOT have functions or routines similar 
to input files. FILNAM and LOKFIL operate exactly as 
described in Pass 5, except that for an output file the 
software must use LOKFIL to make sure that the specified 
file does not exist. OPNOT creates a file name in the 
directory, reserves space for this file on the diskette, and 
performs various housekeeping functions with the file 
buffer area, to prepare for calls to BLKOT, BYTOT, or 
FDWRT. BLKOT writes one disk block onto the disk and 
reserves another block of disk space for the next BLKOT or 
CLSOT call. BYTOT and FDWRT send one character at a 
time from the C register to the output file. The output file 
of BYTOT is specified by the file buffer area pointed 
to by the HL register pair when BYTOT is called. FOWRT 
always uses the system output file buffer area WRTFIL, 
and writes to the file currently associated with that buffer. 
After all data has been written with BLKOT, BYTOT, or 
FDWRT, CLSOT must be called exactly once for each 
output file. If CLSOT is not called, the data in this file 
will probably be lost. 

Multiple files can be open for input and output at the 
same time. The only restriction on the number of files 
simultaneously open is that each must have its own unique 
file buffer area. After an output file has been closed, the 
file buffer area can be reused for input, output, or general 
data storage. 


PASS 7: Re-entering FDOS, 


File Deletion and Renaming 


In this chapter, five User Accessible Routines (UARs) 
will be described. These are BEGIN, RESTRT, INIT, 
DELETE, and RENAME. These are routines which will be 
needed for development of software which performs exten- 
sive or complex file manipulation. Programs such as text 
editors, assemblers, compilers, and various data base sort 
and merge programs will use these UARs. 


Returning to FDOS 


FDOS is the operating system for the computer and for 
all programs that use any of the FDOS routines. Whenever a 
user’s program has completed execution, it should return 
control to FDOS. There are several ways of returning to 
FDOS from a user’s program: by a jump to the starting 
address of FDOS (normally DOOOH), or by calling or 
jumping to either of two UARs BEGIN or RESTRT. 

Table 7.1 shows six ways to return to FDOS after a pro- 
gram completes execution. At the present time, all of these 
methods are exact equivalents. However BEGIN and 
RESTRT are reserved for separate functions in later ver- 
sions of FDOS, and the user should incorporate these UARs 
accordingly. 

BEGIN is a routine to be used when one wishes to enter 
or re-enter FDOS with no regard to what programs may 
have been executed in the past. A program which completes 
execution and will not require any further action will call 
or jump to BEGIN (FDOS+34). Either a CALL or a JMP 
will work because the BEGIN entry point causes FDOS to 
reset the stack pointer and will not perform a return 
instruction corresponding to the call. Therefore, in this 
special case CALL and JMP are equivalent. 

The RESTRT routine (or entry point) is for use by 
programs which require chaining or some other form of 
continued action. Chaining is a method where one pro- 
gram completes execution and then causes another pro- 
gram to execute immediately afterwards. The second 
program is said to be chained to the first program. Because 
the two (or more) chained programs may occupy the same 
memory space, the first program cannot directly read in 
the second program by any simple use of BLKIN, BYTIN 
or FDREAD. By chaining two programs together via a 


RESTRT call to FDOS, the user need not worry about 
what memory locations are required by either program. 
An example of chained programs would be an edit program 
which, upon completion of editing a disk file of source 
code, caused a FORTRAN compiler to be brought in to 
compile the source code file. The FORTRAN compiler 
could, in turn, be chained to the compiled code file, so that 
when compilation was complete, the compiled program 
would be read in from the disk and executed. Full details 
on the chaining of programs are presented in Appendix N. 

When returning to FDOS from your software, use the 
appropriate re-entry point. If you are simply returning to 
FDOS so that the user may request the next program to be 
run, use the BEGIN entry point. If you require, or may in 
the future require, the program that is being exited to cause 
another program to run, then use the RESTRT entry point 
of FDOS. 


Disk Drive Initialization (INIT) 


The User Accessible Routine INIT is a hardware- 
dependent routine. When INIT is called, it causes all disk 
drives which are currently attached to the computer to 
move the disk heads to track zero. In addition, any other 
hardware or software functions required to make the disk 
drives operational are performed. These functions include 
setting the software track counters to zero in the version 
of the disk interface included in this book. For those ver- 
sions of FDOS which make use of other disk driver hard- 
ware and software (see Appendix L) these functions will 
vary. 


SANSA 


er 


FDOS start location 


Table 7.1: Six ways to return to FDOS after a program 
completes execution. 
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It is recommended that the user call the INIT routine 
any time that a different disk is loaded into a disk drive. 
Extra calls to INIT may slow down your software by a few 
seconds for each call, but it is good insurance against un- 
usual forms of errors caused by mechanical malfunctions 
of the disk drives. INIT destroys all registers. 


Removing Files (DELETE) 


Pass 1 described how PIP could be used to delete files 
from the disk. The programmer does not need to use PIP 
to delete a file, however. The FDOS User Accessible 
Routine DELETE can be used quite simply to perform this 
function. To use DELETE, the programmer first must set 
up a file buffer area as if the file to be deleted were about 
to be opened. The user should then use LOKFIL to assure 
that the file does in fact exist. If it does exist, call DELETE 


with the HL register pair pointing to the file buffer area of 
the file to be deleted. 

Example 7.1 shows a simple program for deleting a file 
of the user’s choice. First, the user is asked what file is to 
be deleted, and the file name is typed in. FILNAM properly 
formats the file name in FBADEL, the file buffer area for 
deletion, and LOKFIL is called to make sure that an 
attempt is not made to delete a nonexistent file. Calling 
DELETE performs the actual deletion, and immediately 
afterwards a jump to BEGIN returns control to FDOS. 
Notice that the statement labeled EXTRA really is super- 
fluous. HL already has the address of FBADEL, unchanged 
by either FILNAM or LOKFIL. The EXTRA statement 
is included purely as a reminder of the conditions needed 
to call DELETE. If the user attempts to DELETE a non- 
existent file, the carry bit is set and DELETE returns 
immediately to the calling program. 

If a file has been opened for output, and data has been 
sent to this file, but the file was never closed with the 


DELASK: DB 

START: LXI H,DELASK 
CALL TXTYP 
CALL TXTIN 
LXI H,FBADEL 
CALL FILNAM 
Jc BADNAM 
CALL LOKFIL 
JC NOSUCH 

EXTRA: LxXI H,FBADEL 
CALL DELETE 
JMP BEGIN 

FBADEL: DS 278 


‘WHAT FILE DO YOU WISH TO DELETE?’ ,O 


;request a file name 
;from the console 
;input the file name 


;put the file name in FBADEL 
;exit if abad name 

;does it exist? 

7NO, sO quit, can not delete it 
yes, load the HL regs (again) 
;delete the file in question 
;return to FDOS 

i file buffer area for deletion 


Example 7.1: How to delete a disk file using the DELETE 


routine. 

ASKREN: DB 

START: LxXI H,ASKREN 
CALL TXTYP 
CALL TXTIN 
LXI H,FBAOLD 
CALL FILNAM 
Jc BADNAM 
CALL LOKFIL 
JC NOSUCH 
LXI H,FBANEW 
CALL FILNAM 
JC BADNAM 
CALL LOKFIL 
JNC EXISTS 
XCHG 
Lxl1 H,FBAOLD 
CALL RENAME 
CALL RESTRT 

FBAOLD: DS 10 

FBANEW: DS 10 


‘ENTER THE OLD, NEW NAMES’ ,O 


;ask for the two names 

;from the console 

;read both in 

;old name file buffer area 

get the file name from TXTIN 
;quit if name is bad 

;does it exist? 

;nope, quit. 

;new name file buffer area 

;get the second name from TXTIN 
;Quit if name is bad 

;does the new name exist? 
yes, quit. 

;DE points to new name 

;HL points to old name 
;rename the file 

;return to FDOS 

shold the old name here 

shold the new name here 


Example 7.2: A short program showing the use of the 
RENAME routine to change the name of a file. 


ij 


CLSOT routine, then this file is called a partial file. If 
DELETE is used to delete a partial file, then ERROR 12 
will be flagged to notify the user of a partial file deletion. 
The partial file will be properly deleted, and all of the disk 
blocks occupied by the partial file will become available 
for other files to use in the future. 

DELETE modifies registers A, B, C, and the status flags, 
and the call to DELETE will take a length of time Propor- 
tional to the length of the file being deleted. A long file 
may take several seconds to delete. 


Changing a File Name (RENAME) 


Pass 2 described a method of using PIP to change the 
name of a file. As with DELETE, the name changing 
routine RENAME is a User Accessible Routine (UAR) 
available to any software that the programmer writes. 
Before calling RENAME, the software must make sure 
that certain conditions are met for RENAME to work 
correctly. First, both the old name and the new name 
must be stored in two separate file buffer areas. Second, 
the file must exist under the old name, of course, and no 
file may already exist with the new name. And finally, 
if all of these conditions are satisfied, RENAME may be 
called with the HL register pair pointing to the file buffer 
area containing the old (current) file name, and with the 
DE register pair pointing to the file buffer area containing 
the new (future) name. 

Example 7.2 is a short program which allows a user to 
change a file name from the console device. In operation, 
this program first types onto the console a request for the 
user to enter two file names. The user enters the names 
separated by a space or a comma, and the program formats 
the first name into FBAOLD, the file buffer area of the 
old name. After using LOKFIL to make sure that this file 
does exist, the program reads the second name into 
FBANEW, the file buffer area of the new name. LOKFIL 
is used again, this time to make sure that the new name 
does not already exist. When all of these conditions are 
established, the DE and HL register pairs are loaded with 
the addresses of FBANEW and FBAOLD, respectively, 
and RENAME is called. After the file has been renamed, 
the program returns to FDOS via a call to RESTRT. 

A special note on the use of RENAME. In example 
7.2 you should notice that the two file buffer areas used 
are each only 10 bytes long, as opposed to the normal 
278 bytes. RENAME only uses the first ten bytes (the 
file specification) because none of the file data is actually 
read or written. Only the file name in the directory is 
changed; no other data in the directory or on the rest of 
the disk is modified. A full sized file buffer area can be 
used, of course, but this feature can save a lot of space 
on the occasion when it can be used. 


If RENAME is called when either no file exists with the 
old name, or a file already exists with the new name, then 
the carry bit is set to indicate that the file was not renamed. 
The user should be careful always that the old and new 
names are both on the same disk drive since a file obviously 


cannot be renamed onto a different disk drive. RENAME 
does not change the B, C, D, E, H, or L registers. 


Using DELETE and RENAME 


A typical application of the use of RENAME and 
DELETE is the adaptation of an edit program to run under 
FDOS. The user would like to always maintain (at least) 
one back up file of edited material on the disk. In the un- 
likely event of a user error, power failure, or system crash, 
the user desires to have the last copy of a source program 
as it existed before the last edit session. Assume that you 
have the following editor specifications: you wish to edit 
a file titled ABLE; another file titled ABLE.BAK may exist 
from the last edit session; after the current edit session is 
successfully completed, the user would like to delete the 
ABLE.BAK file (if it exists), rename the old ABLE file 
to ABLE.BAK, and then rename the edited output file 
from the current edit session as ABLE. 

To accomplish this, the routines shown in example 7.3 
could be added to the start and the end of a paper tape 
oriented editor program. Two simplifying assumptions 
have been made to clarify and shorten this example: all 
files to be edited are to be on the disk in drive 0; and the 
file to edit already exists (we are not creating the file with 
the editor). 

In execution, example 7.3 operates as follows: 


START: The software requests a file name via the 
console, and this file is opened for input. If an 
invalid name is entered or the file does not exist, 
control is transferred to an unspecified ERROR 
routine. 

OUTFIL: A file EDITOR.TMP:0 is created that will 
record all of the output from the editor. If this 
file already exists, the program branches to 
ERROR. 

EDIT: The user supplied editor belongs here. All 
input and output is done byte by byte with the 
User Accessible Routines (UARs) BYTIN and 
BYTOT using the file buffer areas FBAIN and 
FBAOUT, respectively. 

CLOSE: When the editor has finished and written 
out the complete edited file, the output file 
EDITOR.TMP:0 is closed by CLSOT. 

MAKBAK: The first six letters of the input (original) 
file name are copied into FBABAK. The file 
extension .BAK:0 already exists in FBABAK, 
so ABLE:0 or ABLE.SRC:0 or ABLE.FTN:0 
or ABLE.anything:0 becomes ABLE.BAK:0 in 
this file buffer area. 

DELBAK: The software now checks to see if 
ABLE.BAK already exists. If it does, then it is 
deleted by a call to DELETE. If it does not, no 
DELETE is performed. 

RENBAK: The file currently known as ABLE, 
ABLE.SRC, ABLE.FTN, etc. is now renamed 
ABLE.BAK. At this point, the previous source 


Example 7.3: Using RENAME and DELETE with an editor 


program. 
ASKNAM: DB ‘FILE NAME TO EDIT?’ ,O 
START: LXI H,ASKNAM =;request the file name to edit 


CALL TXTYP 
CALL TXTIN 


LX! H,FBAIN 
CALL FILNAM ;put the name in FBAIN 
JC ERROR 
CALL LOKFIL ;does the file exist? 
JC ERROR ;nope, quit 
CALL OPNIN 7yep, open it for input 
OUTFIL: LXI H,FBAOUT ;open for output the file titled 
CALL OPNOT ;EDITOR.TMP:0 
JC ERROR ;quit if it already exists. 
EDIT: 
;the editor program goes here, all input is done via 
; LXI H, FBAIN 


CALL BYTIN 
swith the character returned in A 
jall output is done by: put the character in C 
; LXI H,FBAOUT 
CALL BYTOT 
eee the editor is finished, the following is performed: 


CLOSE: LX! H,FBAOUT close the output file 
CALL CLSOT 


MAKBAK: LXI H,FBABAK ;convert the backup file buffer 
LXI D,FBAIN jarea to contain the name.BAK 
MVI C6 ;by moving only the first 6 characters 
LOOP: LDAX D 
MOV M,A 
INX H 
INX D 
DCR Cc 
JNZ LOOP smove 6 letters 
DELBAK: LXI H,FBABAK check for name.BAK existence 
CALL LOKFIL 
CNC DELETE iif present, delete. if not, skip. 
RENBAK: LXI D,FBABAK ;new name 
LXI H,FBAIN ;old name 


CALL RENAME _ ;change file name to file name.BAK 


RENTMP: LXI D,FBAIN ;new name 
LXI H,FBAOUT ;old name 
CALL RENAME _ ;change EDITOR.TMP to file name 


EXIT: JMP BEGIN sreturn to FDOS 

FBABAK: DS 6 
DB ‘BAK'O ;name is blank.BAK:0 
DS 268 ;rest of FBA 

FBAIN: DS 278 ;read in file 

FBAOUT: DB ‘EDITORTMP’0 __ ;file named EDITOR.TMP:0 
DS 268 


S3_.6_uwoNs=saoR oO 


file becomes the current backup file. 

RENTMP: The file created by this editing session, 
now named EDITOR.TMP (for temporary editor 
file), is renamed with the name of the file orig- 
inally edited. 

EXIT: Having completed its assigned task, the editor 
returns control to FDOS. 


This powerful method of automatic backup file creation 
and deletion assures the user of having a current copy and 
at least one backup copy of a file at all times, and requires 
no effort or file manipulation by the user. Advanced 
programmers who wish to incorporate these routines into 
their software can see the few changes needed to eliminate 
the simplifying assumptions of file pre-existence and disk 
zero residency. The REDFIL and WRTFIL file buffer areas 


can be used to reduce the amount of memory required by 
this software. 


Summary 


This chapter showed that a user written program can 
return to FDOS by a jump or a call to FDOS, BEGIN, or 
RESTRT. If the programmer wishes to delete or rename 
files, this can be done without PIP simply by setting up the 
proper file buffer areas and calling DELETE or RENAME. 
Finally, a practical example was described to show how 
easily RENAME and DELETE can be used to convert a 
simple paper tape editor into a powerful file based editor 
with automatic file backup protection and deletion features. 


PASS 8: Directory Organization 


This chapter describes the organization of the FDOS 
directory, the table of contents of the disk. 


Location 


Track 2 on all disks using FDOS is used for the direc- 
tory, which is composed of a bit map and a section of file 
entries. The first block of track 2 (starting at sector 0) is 
used to store the bit map described later in this chapter. 
When a double-density, full-sized floppy disk is used with 
FDOS, the bit map will be stored on the first and second 
blocks of track 2. The file entries themselves are stored 
on the remaining blocks of track 2, with each block holding 
the entries for 16 different files. This allows up to 112 
different files to be in the directory of a 5 inch floppy, 
240 files on a double-density 5 inch or single-density 8 inch 
floppy disk, and up to 480 different files on an 8 inch 
double-density disk. Track 2 is used only for directory 
storage, never to hold file data. 


File Entries 


The directory is composed of the same type of disk 
data blocks as all of the data files described previously, 
except that the directory blocks are not linked with for- 
ward and reverse links (so they cannot be read or written 
with BLKIN, BLKOT, BYTIN, or BYTOT). This means 
that 256 bytes of each block hold the directory informa- 
tion, divided into 16 file entries of 16 bytes each, as shown 
in table 8.1. 


Bytes 0 thru 8: Constitute a string of 9 ASCII char- 
acters which form the 9 character file name (6 
letter base name plus a 3 letter extension) of 
the linked data file that this directory entry refers 
to. If the file was named with less than 9 letters, 
then the base name is filled to 6 positions with 
spaces and the extension is filled to 3 positions 
with spaces. There are two special instances of 


byte 0 in the file entry: if byte 0 of this entry is 
zero (all bits cleared) then this entry is empty 
(does not yet represent any file) and all following 
entries in this block or any following blocks on 
track 2 are empty; a program searching through 
the directory for some entry, and finding a first 
byte of 0 in an entry, can stop searching as there 
will be no further entries. This feature saves a lot 
of time on disks with only 10 or 20 files. 

If byte 0 has the most significant bit set, then 
this 16 byte directory entry was a valid entry 
which has been deleted and is no longer valid. The 
file that this directory entry used to represent has 
been removed from the disk. Note that by setting 
this single bit, no information about the old file 
is lost and the old data can be utilized in certain 
complex crashed-disk data recovery programs 
that the advanced hacker will delight in. 


Byte 9 and 10: Indicate the track and sector, respec- 


tively, of the first block of the linked file. All 
other blocks of the file are accessed by sequen- 
tially reading blocks, finding the pointer to each 
succeeding block from the block just read. 


Byte 11: Uses the six least significant bits to repre- 


sent the day of the month in Binary Coded Deci- 
mal (BCD), from 01H to 31H, on which this file 
was created. The two most significant bits are used 
for the block count overflow described below. 


Byte 12: Uses the four least significant bits to repre- 


sent the month of the year (01H to OCH) that this 


DESCRIPTION 


BYTE 
Ques May indicate end of directory or a deleted entry 
O thru8 9 byte file name in ASCII format 
9 Track of the first block in the linked file 
10 Sector of the first block in the linked file 
“41 Day of month of file creation, 
: : block count overflow 
12 Month and Year of file creation 
13 Block count of the file length 


14 and 15 — Reserved for future use 


Table 8.1: Disk directory file entry format. 
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file was created. The four most significant bits 
are used to represent the current year minus 1975. 
1977 is represented by 20H, 1978 by 30H, and 
so forth to 1991 (FOH), after which the cycle re- 
peats (and FDOS is probably obsolete anyway). 

Byte 13: Holds the number of blocks (each block 
representing 256 data bytes) which comprise the 
file. If more than 255 blocks are contained in one 
file, the overflow bits are stored in the 2 most sig- 
nificant bits of byte 11. This allows enumeration 
of up to 1023 blocks holding over one quarter 
million bytes. 

Bytes 14 and 15: Reserved for future use. 


Examples given below describe how the FDOS routines 
FILNAM, OPNIN, OPNOT, and CLSOT use this directory 
structure. 


Searching the Directory for a File 


The FILNAM routine described previously is used to 
search the disk directory for a file entry whose 9 letter file 
name is the same as the 9 letter name stored in memory 
(in a file buffer area) and pointed to by the HL register 
pair. In operation, FILNAM reads in the second data 
block of track 2, the first block containing file entries. 
The data area of this block, consisting of 16 file entries, 
is searched for an entry that either has zero as the first 
byte, or an entry whose first 9 bytes match the first 
9 bytes of the requested file name. If neither of these 
conditions is satisfied in the first 16 file entries, the 
next block of file entries is read in and the process is 
repeated. 

If at any time during this process a perfect match is 
found, then FILNAM returns to the calling program with 
the carry bit cleared to show that the file was found, and 
with the DE register pair pointing to the first byte of the 
16 byte matching file entry. If a file entry with an initial 
zero byte is found, FILNAM returns to the calling program 
immediately with the carry bit set to indicate that no such 
file exists in this directory. Similarly, if all of the directory 
blocks are exhausted before either a match or a zero entry 
is found, then the carry bit is set and FILNAM returns. 


Opening a File for Input 


The FDOS routine OPNIN is used to initialize a disk 
data file for input. OPNIN searches the directory in the 
manner described for FILNAM until it finds the desired 
file entry. After finding the file entry, the track and sector 
of the first data block are copied from the directory file 
entry into the file buffer area, to allow the various FDOS 
file input routines (BYTIN, BLKIN) to access this linked 
file. If OPNIN fails to find the desired file in the directory, 
an ERROR 04 is flagged to notify the user of an unsuccess- 
ful attempt to open a non-existent file for input. 


Opening a File for Output 


OPNOT was described previously in its application for 
opening a file for output. In actual operation, OPNOT 
first uses FILNAM to assure that no file with the same 
name as the new file already exists on the directory. If 
such a file does exist, ERROR 03 is flagged to alert the 
user to the problem. If no duplicate exists, then OPNOT 
goes back to the beginning of the directory and searches 
all of the directory entries a second time. This time, the 
search finds the first file entry where the first byte of the 
entry is either a zero (first empty entry beyond all cur- 
rently used entries), or has the most significant bit set 
(a previously deleted entry). OPNOT copies into this 16 
byte file entry area the 9 character file name, the current 
date, and the track and sector of the first free data block 
on this disk. The concept of a free data block is described 
later in this chapter. The updated directory is then copied 
back onto the disk. If the OPNOT routine cannot find a 
free block, ERROR 06 is flagged to indicate that the disk 
drive is full and no more data can be entered. If OPNOT 
cannot find any unused file entry area in the directory, 
then ERROR 05 is flagged to indicate that the directory 
is full. 


Closing an Output File 


The OPNOT routine made no record of the length of 
the file in the file buffer area, because the length of the 
file is not known at the time that the file is created. When 
the entire file has been written onto the disk and the 
CLSOT routine is called, CLSOT updates the directory 
entry by entering the number of blocks in the file into 
bytes 11 and 13 of the file entry. 


The Bit Map 


In the preceding section the concept of a “free data 
block” was mentioned without any explanation. A free 
data block on the disk is any data block that is not part of 
the directory or part of any existing data file. When writing 
a file out to the disk, data blocks must be used to store the 
file, and they must be blocks that are not already used by 
some other file. In order to decide which blocks to link 
onto a file being written, FDOS must have a method of 
determining which blocks are free. FDOS could read each 
disk block sequentially until a free block is found, but this 
might entail reading in hundreds of blocks for each block 
written. To perform this function more quickly, a bit map 
is employed. 

The bit map is a series of data bytes where each bit of 
each byte corresponds to, or more technically, is mapped 
to (hence “bit map”) one of the disk blocks of data. All 
free blocks are denoted by zeroes, and all blocks which are 
currently in use are denoted by ones. The advantage of this 
scheme is that a complete record of the availability status 


(free or not free) of all data blocks of a full-sized disk can 
be stored in less than 150 bytes of data, can be quickly 
transferred to or from the disk, and is easily searched for 
free blocks. A 5 inch floppy disk contains 32X8=256 or 
37X8=296 blocks of file data, which means that the bit 
map need be only 32 or 37 bytes long. A full-sized disk 
requires 74X16=1184 blocks of file data or 148 bytes of 
bit map data. 

As a linked file is written, each block of data used by 
the linked file causes the corresponding bit in the bit map 
to change from a 0 to a 1. When a file is closed, the up- 
dated bit map is written out onto the disk. When a file is 
deleted, map bits which correspond to the data blocks 
used by the deleted file are cleared to 0. In this way the 
pool of available (‘free’) blocks contracts and expands 
as files are created and deleted, and maximum use is con- 
tinuously made of the disk data area. 

An additional benefit to this scheme is the ability to 
utilize damaged floppy disks with FDOS. If you have a 
disk with some number of data blocks which are physically 
damaged, such that they cannot store data reliably, then 
you need only set the bits in the bit map which correspond 


to these blocks. Setting these bits will remove the damaged 
blocks from the free block pool, and no files will ever try 
to write on them. Conversely, since these blocks do not 
belong to (are not linked to) any disk file, no file deletions 
will ever return these damaged blocks to the pool of free 


blocks, and FDOS will continue to avoid these blocks 
automatically. 


Summary 


This chapter described the FDOS directory located on 
track 2 of each floppy disk. The directory is made up of a 
bit map which keeps track of free blocks, and a section of 
file entries. File entries are all 16 bytes long, and contain 
the file name, a pointer to the first block of the linked file, 
the date of file creation, and the number of data blocks in 
the file. A description of the operations of LOKFIL, 
OPNIN, OPNOT, and CLSOT was given to illustrate the 
operation of the directory and the bit map. 
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PASS 9: Random Access to Disk Data Blocks 


All data files discussed to this point have been linked 
files, and all access to these files for both input and output 
have been performed sequentially, always from the begin- 
ning of the file to the end of the file. All access to the 
data stored on the disk has been discussed in previous 
chapters by use of the FDOS routines OPNIN, OPNOT, 
BLKIN, BLKOT, BYTIN, BYTOT, FDREAD, FDWRT, 
and CLSOT. These routines allow FDOS to perform a great 
deal of error checking and file management. While these 
file management tasks make the use of file access routines 
much simpler, the user is constrained to always read or 
write the next byte or block in a linked file. None of these 
routines allow the user to randomly access data, simply 
reading or writing the block at track 12, sector 6, for 
example. 

One good reason for preventing the user from writing to 
track 12, sector 6 is the possibility that this block of 
data is part of a linked data file. If this is the case, then 
writing a new block of data will wipe out the previous 
contents of this block, and will probably also destroy the 
forward and reverse file linkages. When these linkages are 
destroyed, the linked file can no longer be read with the 
FDOS linked file input routines, and all of the data beyond 
this rewritten block in the file is no longer accessible. An 
even bleaker prospect is the case when the block written 
over is the bit map or a directory block. Either of these 
eventualities would render most or all of the data on the 
disk inaccessible by normal FDOS routines, destroying 
weeks or months of programming effort. 

The preceding scenario is intended mainly to caution 
the user to perhaps avoid the routines described in this 
chapter. The danger of data loss is very real, but is over- 
weighed in many instances by the fact that there are 
numerous vital disk operations that simply cannot be 
done without these routines. 


Random Input 


The user may randomly read in any data block on the 
disk with the FDOS User Accessible Routine RNDIN. 
RNDIN is not dangerous in itself, as it only inputs data 
from the disk, and does not modify any disk data. 

RNDIN is very similar to BLKIN in how it is called and 
what it does, but the important differences must be noted. 


First, to call RNDIN, the HL register pair must point to a 
file buffer area similar to calling BLKIN. However, the file 
buffer area must be a full 280 bytes long, for RNDIN 
transfers all of the data in from the disk data block, in- 
cluding the check sum. The file name, if any is present 
in the file buffer area before the read operation, is ignored 
by RNDIN. 

RNDIN is used to read a block of disk data, where the 
block is specified by the disk number, the track, and the 
sector to be read instead of the file name that BLKIN uses. 
Before calling RNDIN, the user must enter the drive num- 
ber, track number, and sector number in bytes 9, 14, and 
15, respectively. Note that this is the disk number and the 
forward link or next track and next sector, as described in 
table 5.1. After the RNDIN routine has completed, all 
bytes of the file buffer area may be modified, including 
bytes 9, 14, and 15. The user must make certain that 
bytes 9, 14, and 15 are loaded with the proper informa- 
tion before each call to RNDIN. 

The BLKIN routine checks both the forward and the 
reverse linkages of the block read each time that it is 
called, and reports any errors to the user on the console 
device. RNDIN does not check these linkages, and will 
not type out any error messages during random access 
to the disk. 

Finally, successive calls to BLKIN automatically read 
successive blocks in a linked file, but RNDIN will not 
necessarily automatically advance through a file. Each 
call to RNDIN must be preceded by loading the desired 
disk drive number, track, and sector into the file buffer 
area, and the OPNIN routine is never used with RNDIN. 
RNDIN does not modify the A, B, C, D, E, H, or L 
registers. 


Random Output 


The user may write data out to any block of the disk 
at random by using the FDOS routine RNDOT, which is 
similar in form and function to the User Accessible Routine 
BLKOT. In Pass 6 the function of BLKOT was discussed 
including the following highlights: 


1) BLKOT calls are always preceded by a call to OPNOT. 
2) BLKOT calls are always ended by a call to CLSOT. 
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Example 9.1: Use of the RNDIN routine to read the disk 


directory. 


BUFFER: 
DATA: 


MvI 
STA 
MVI 
STA 
MvVI 
STA 
LXI 
CALL 
LXI 


DS 
DS 


AO 
BUFFER+9 
A,2 
BUFFER+12 


A 
BUFFER+13 
H,BUFFER 
RNDIN 
H,DATA+16 


rest of program 


21 
259 


jindicates drive 0 

store in byte 9 

jtrack 2 

store in byte 12 

sblock 4 = sector 6 
jstore in byte 13 

;HL points to buffer 
call the RNDIN routine 
;HL points to 34th entry 
jin the directory 


;first 21 bytes are housekeeping 
;256 data bytes + check sum 


Example 9.2: Use of the RNDOT routine to change data in 


a selected file block. 
LX! H,CSTBUF 
CALL OPNIN 
JC ERROR 
LOOP1: LX! H,CSTBUF 
CALL BLKIN 
JC ERROR 
LXI H,CSTDAT 
CALL COMPAR 
JC FOUND 
LXI H,CSTDAT+64 
CALL COMPAR 
JC FOUND 
LXl H,CSTDAT+128 
CALL COMPAR 
JC FOUND 
LXI H,CSTDAT+192 
CALL COMPAR 
JC FOUND 
JMP LOOP1 
FOUND: CALL REPLAC 
LXI H,CSTBUF 
CALL RNDOT 
JMP FDOS 
CSTBUF: DB ‘CSTMRS ',0 
HOUSKP: DS 11 
CSTDAT: DS 259 
ERROR: 


COMPAR: 


i 
88 —— 


;file name is already present 
open CSTMRS for input 

jgo to error routine if unopenable 
read in the next data block 
;using the BLKIN routine 
read error, or end of file jump 
icheck first entry this block 
jcompare to desired name 
jcarry set means a match found 
;check second entry this block 
jcompare to desired name 
;carry set = match 

;check third entry 

;compare to desired name 
;carry set = match 

;check last entry this block 
;compare to desired name 
;carry set = match 

;not this time, try next block 


replace the old data 

;point to the file buffer area 
;BLKIN supplied disk number, track 
jand sector 

;then return to FDOS when done 


;file name to update 
711 bytes of housekeeping data 
;259 bytes of data and check sum 


This routine outputs some error message to the user. 

This routine compares the customer name pointed to by HL to the 
desired name and sets the carry bit if a match is found. 

REPLAC: This routine replaces the old address with the new address. 


3) Each BLKOT call acquires a successor data block from 
the pool of free data blocks and establishes a forward 
linkage to that successor block. 

4) BLKOT will not write over the bit map, the directory, 
or any existing linked file. 

5) BLKOT can only lengthen a linked file, it cannot modify 
previously recorded data. 


In contrast to these features, RNDOT operates as 
follows: 


1) RNDOT calls are not used with OPNOT. 

2) RNDOT calls are not ended with CLSOT. 

3) RNDOT makes no changes in the bit map, and will not 
establish any linkages automatically. 

4) RNDOT, carelessly used, can destroy the bit map, the 
directory, or any existing data files. 

5) RNDOT can be used to modify any or all of a single 
data block in a linked file without changing any of the 
rest of the blocks in the file. 


To use RNDOT the user simply puts the data to be 
written onto the disk into a conventional file buffer area. 
The user must then put the desired disk drive number, 
track, and sector into bytes 9, 10, and 11 of the file buffer 
area, as in table 4.1. The HL register pair is loaded with 
the address of the first byte of the file buffer area, and 
then RNDOT is called. RNDOT will calculate the required 
check sum value, but it will not change any other data 
before writing the entire file buffer area out to the data 
block at the desired track and sector of the desired disk. 


Examples 


The most frequent use of RNDIN is to examine either 
the bit map or the directory, since these are not part of 
any linked file. An attempt to read these blocks with a 
BLKIN routine will result in an ERROR 07 message. 
If, for instance, you wished to look at the thirty-fourth 
entry in the directory of disk zero, you would wish to read 
in the second entry of the third directory block, which is 


the fourth block (starts on sector 6 of a single-density 
disk) of track two. This could be done as shown in 
example 9.1. 

RNDOT is easily used to modify data stored in a previ- 
ously written linked file. Assume for our example that 
a file named CSTMRS stores the names and addresses of 
business customers, and that one customer has changed 
his address. Because CSTMRS is a very long file, you wish 
to change the stored address without recopying the entire 
file. Further assume that each customer name and address 
is stored in a 64 character block of data in the file, with 
four customers stored in each linked data block. Exam- 
ple 9.2 reads through the customer file until it finds the 
desired customer. The customer data is changed and re- 
recorded onto the disk by RNDOT. Some of the functions 
that are not related to FDOS and RNDOT are only shown 
by calls to their function in order to simplify the example. 

Note that after the data was replaced, RNDOT was 
called without any entry of disk number, track, or sector 
number. That is because the routine BLKIN brings this 
data into the buffer in the manner in which it should be 
replaced on the disk for the linked file to remain properly 
linked. BLKIN and RNDOT are made to work together in 
exactly this manner. Note: RNDIN and RNDOT cannot 
be used in this manner, since the disk drive number may 
have to be changed. Once again it should be stressed that 
great care should be exercised when using RNDOT. 


Summary 


Random access to read and write disk data blocks may 
be accomplished by the RNDIN and RNDOT routines, 
respectively. RNDIN is similar to BLKIN but requires a 
slightly larger buffer area. The user puts the disk number, 
track, and sector to be read into the file buffer area before 
calling RNDIN. RNDOT is similar to BLKOT but will not 
record the written blocks in the bit map, nor will it provide 
linkages nor protect existing files from destruction. 
RNDOT must be used with caution since it allows the 
user to write over any part of the disk indiscriminately. 
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PASS 10: MODCAL and Its Uses 


This chapter is devoted to a single User Accessible 
Routine (UAR) called MODCAL. MODCAL was included 
in the set of UARs to allow programs using UARs to be 
relatively independent of the location of FDOS. 

The rapid proliferation of 8080 hardware and software 
largely lacks any standardization of what memory space 
is used for what purpose. Existing hardware and software 
may occupy specific memory spaces which conflict with 
FDOS. The address space of FDOS in this book is repre- 
sented as between ODOOOH and ODFF7H; however, on 
systems where this space is used for memory mapped 
1/0, video display memory, or monitor programs, FDOS 
may be reassembled into some other 4 K block of memory. 

If you write a program which contains fifty calls to 
various UARs and ten references to the User Accessible 
Addresses (UAAs), then to use this program on a computer 
system with a relocated FDOS will require that you change 
sixty different references in the program, or else com- 
pletely reassemble the source code. This is a great incon- 
venience and makes programs less transportable and less 
interchangeable than is ideally possible. To correct this 
problem, the User Accessible Routine MODCAL is included 
in FDOS. 


MODCAL 


Modcal is located at an offset of 88H from the beginning 
of FDOS, and is called as shown in example 10.1. 

The only purpose of MODCAL is to call any of the other 
UARs. MODCAL performs no function of its own except 
to modify the Accumulator and the PSW before calling the 
desired UAR. Since most UARs also modify the PSW and 
Accumulator, this is no great problem. Note that a call to 
MODCAL returns to the second byte following the call 
in the calling program. The byte following the call to 
MODCAL tells which UAR or UAA is being requested. 
Example 10.1 is equivalent to a call to CO, the console 
output routine. Appendix A gives a table of the UARs 
and their locations relative to FDOS. The column labeled 


MODCAL VALUE shows what value would be used in 
place of the DB 03H value in example 10.1 to use 
MODCAL to call that particular routine. So, to type out 
a string of text, instead of using TXTYP directly, one 
could program what is shown in example 10.2. All of 
the UARs can be called in this manner, except for 
MODCAL, which can not call itself. 


Using MODCAL to Access UAAs 


Examination of Appendix B discloses a column of 
MODCAL VALUES for the User Accessible Addresses 
(UAAs). Calling MODCAL with these values after the call 
will cause the HL register pair to be loaded with the corre- 
sponding address from the UAAs. 

In example 10.3, the instruction at label A performs the 
same function as the instruction and value at label B, with 


CD 88 DO CALL MODCAL 
03 DB 03H 
XX XX XX next instruction 


Example 10.1: The format for a call to the MODCAL 
routine. 


TEXT: DB ‘THIS IS A TEST OF MODCAL,PRESS<cr>’,0 
TEST: LX! H,TEXT ;HL points to text 

CALL MODCAL _ ;call the MODCAL routine 

DB 15H 315H=21.=TXTYP routine 

CALL MODCAL _ ;wait fora<cr> 

DB 17H 317H=23.=TXTIN routine 

JMP TEST jrepeat forever 


Example 10.2: Executing the TXTYP routine to output a 
string of text by calling MODCAL. 


seek wes Se ee 
—————————————————————————me 
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the exception that the B method will modify the accumula- 
tor and the PSW. 


FDOS Position Independence 


The preceding examples show how to use MODCAL to 
perform all of the User Accessible Routines (UARs) and 
access all of the User Accessible Addresses (UAAs) within 
FDOS, but it has a major drawback: each call or access 
still requires one reference to the address of FDOS. Using 
MODCAL in this manner, the initial program described at 
the start of this chapter would still require sixty references 
to be changed if FDOS were moved. However, this is not 
the manner in which MODCAL is best used. 

Example 10.4 shows a second way of calling MODCAL. 
Note that all references to MODCAL are made by the jump 
at label POINT. Each call to POINT is followed with the 
MODCAL value, just as if the call to POINT were a call to 
MODCAL. To FDOS and MODCAL, there is no difference 
between example 10.2 and example 10.4. To the user there 
is a major difference; no matter how many calls to UARs 
and accesses to UAAs are in the user’s program, the pro- 
gram can be written with only one call to MODCAL, only 
one address that is located in FDOS. If the program is trans- 
ported to a system with a relocated FDOS, only one byte in 
the entire program need be changed: the most significant 
byte of the address of MODCAL in the JMP MODCAL in- 
struction. This fulfills the requirement for FDOS position 
independence. 


Using RST with MODCAL 


Finally, there is a third method of calling MODCAL, 
through the use of the RST instructions. By dedicating one 
of the RST instructions to always call a transfer to MOD- 
CAL, two byte implementations of MODCAL become 
possible. 

Example 10.5 shows an implementation of the two byte 
MODCAL in a program to list a user specified file from the 


disk to the list device. The 8080 treats the RST 1 (a one 
byte instruction) as a CALL O8H. At location 8, control 
is transferred to the MODCAL routine which completes 
the desired UAR. If example 10.5 seems unclear, make a 
detailed comparison to example3.4 for further information. 

An extra benefit of the RST method of calling MOD- 
CAL is reduced program size. As mentioned above, the RST 
call to MODCAL requires two bytes, whereas the normal 
call direct to the desired routine requires three bytes of 
code. This small savings becomes very important if you are 
patching FDOS into an existing program without the bene- 
fit of the source code for reassembly. 


Errors 


If MODCAL is called with an illegal value following the 
call (a value that does not appear in either the UAR or 
UAA MODCAL VALUE lists of Appendices A and B) then 
MODCAL will return immediately to the calling program 
without executing any of the FDOS routines. In all cases 
of correct or incorrect values, direct, indirect, or RST calls, 
MODCAL returns to the instruction following the value 
byte. Calling MODCAL without the value byte will cause 
errors in your program and should be avoided. 


Summary 


MODCAL is an address within FDOS that can be used to 
call any of the UARs or to load the HL register pair with 
any of the UAAs. MODCAL modifies the accumulator and 
the PSW, but in all other respects acts exactly as the routine 
called would act. MODCAL can be called in the three ways 
shown in example 10.6, all of which perform a Cl routine, 
returning a console character in A. Using a RST instruction 
reduces the memory needed for the calls to UARs, and 
channeling all calls to MODCAL through a single address 
allows you to run a program on a relocated FDOS with 
only a one or two byte patch. 


SSS. LT 
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A: LHLD 


REDFIL 


next instruction 


B: CALL 


DB 


MODCAL 
81H 


next instruction 


Example 10.3: Using MODCAL to access User Accessible 


Addresses, 


=.°.3.3.3.3..°=—-—-sSsq|sroeeeee—— 


TEXT: DB ‘THIS IS A TEST OF MODCAL’,O 

TEST: LXI H,TEXT 7HL points to text 
CALL POINT :call MODCAL through point 
DB 15H ;15H=21.=TXTYP routine 
CALL POINT ;wait for a < cr > 
DB 17H 317H=23.=TXTIN routine 
JMP TEST ;repeat forever 

POINT: JMP MODCAL _ ;the only reference to FDOS 


Example 10.4: Using the MODCAL routine to eliminate the 
use of fixed addresses of routines within FDOS. 


ORG 8 jlocation of RST 1 transfer 
JMP MODCAL - ;all RST 1s become call MODCALs 
LIST: LXI H,NAME ;request the file name 
RST 1 scall MODCAL 
DB 15H 7;15H=21.=TXTYP 
RST 1 ;get the name of the file 
DB 17H 317H=23.=TXTIN 
RST 1 jload HL with (REDFIL) 
DB 81H 3;= LHLD REDFIL 
RST 1 
DB 13H 713H=19.=FILNAM 
JC ERROR ;if illegal name, quit 
RST 1 
DB 14H 714H=20.=LOKFIL 
Jc ERROR jno such file, quit 
RST 1 
DB 10H 710H=16.=OPNIN 
LOOP: RST 1 
DB 9H jcall FDREAD 
JC EOF sif end of file, then finish 
MOV C/A ;LO requires ASCII in C 
RST 1 
DB 5 call LO 
JMP LOOP jand do it again 
EOF: RST 1 ;when finished, return to FDOS 
DB 0 ;call BEGIN 
NAME: DB 'WHAT FILE TO BE LISTED?’,0 


Example 10.5: An implementation of MODCAL in a pro- 
gram to list a user specified file from the disk to the list 
device, 


ORG 10H 
JMP MODCAL 


WAY 1: CALL MODCAL 
D 


B 1 ;Cl 
WAY2: CALL 10H 
DB 1 ;Cl 
WAY3: RST 2 
DB 1 :Cl 


Example 10.6: A summary of the 3 ways that MODCAL 
can be called. 


——— 
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APPENDIX A: User Accessible Routines (UARs) 


RESTRT 
INIT 


FDREAD 
FDWRT 
BYTIN 
BYTOT 
BLKIN 
BLKOT 
RNDOT 


OPNIN 
OPNOT 


CLSOT 
FILNAM 


LOKFIL 
TXTYP 
Til 

TXTIN 
DELETE 
RENAME 
MEMCHK 


RNDIN 
MODCAL 


OFFSET 
34H 
37H 
3AH 
3DH 
40H 
43H 
46H 


49H 
4CH 


4FH 
52H 
55H 
58H 
5BH 
5EH 
61H 


64H 
67H 


6AH 
6DH 


70H 
73H 
76H 
79H 
7CH 
7FH 
82H 


85H 
88H 


MODCAL 
VALUES 


0 


So © ON ANRPWNH— 


REGISTERS 
MODIFIED 


A,F others 


DESCRIPTION 


This routine transfers control to FDOS 

Returns one ASCII character from the console in A 
Returns one byte from the paper tape reader in A 
Types the ASCII character in C onto the console 
Punches the byte in C onto the paper tape punch 
Prints the ASCII character in C onto the list device 
Returns A=0 if no character ready, A=OFFH if 
character is ready for Cl 

Returns to FDOS for calling in chained programs 
Moves all disk heads out to track 0 and initializes 
all drives 

Returns next byte from input file of REDFIL 
buffer area in A 

Writes the byte in C to output file of WRTFIL 
buffer area 

Returns next byte in A from input file of buffer 
area pointed to by HL 

Writes the byte in C to the output file of the file 
buffer HL points to 

Reads one block (278 bytes) of data into the file 
buffer HL points to 

Writes one block of data to disk from the file 
buffer area HL points to 

Writes the block pointed to by HL onto the disk 
block of buffer bytes 10 and 11 

Opens the buffer area pointed to by HL for input 
Opens the buffer area pointed to by HL for output 
(creates a new file) 

Closes the output buffer area pointed to by HL 
Transfers a file name from TXTIN buffer to the 
buffer area pointed to by HL 

Looks up file of HL buffer area, returns Carry 
clear if file exists; DE points to entry 

Type ASCII character text to CO starting at HL, 
ending with 0 or most significant bit (MSB) set 
Return next ASCII character from the TXTIN 
buffer in A 

Edit a line from Cl into a buffer with Rubout, “X, 
Ax, and “C routines 

Delete the file whose buffer area is pointed to by 
HL 

Rename the file whose buffer area is pointed to by 
HL with new name at DE buffer area 

Find the highest contiguous memory seament, 
return address in B (most significant byte), A (least 
significant byte) 

Read the disk block of bytes 14 and 15 of buffer 
area at HL into that same area 

Calls one of above routines according to byte 
following the call (MODCAL VALUE column) 
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APPENDIX B: User Accessible Addresses (UAAs) 


MODCAL 


TITLE OFFSET VALUES DESCRIPTION 
- 28H 80H Reserved for future use 

REDFIL 2AH 81H Address of File Buffer Area for FDOS disk file 
read operations. 

WRTFIL 2CH 82H Address of File Buffer Area for FDOS disk file 
write operations, 

DAYOM 2EH 83H Address of current date in two bytes; Day, 
Month, and Year. 

TXTPNT 30H 84H Address of the two byte text buffer pointer, 
followed by the text buffer. 

LSTERR 32H 85H Address of the byte of memory containing the 


number of the last FDOS error. 


REDFIL contains the address of a 278 byte file buffer area in memory. This is the file buffer area 
used by FDOS to read programs in response to the RUN command. Once a program is in memory, 
the REDFIL buffer can be used as a file buffer area by the user’s program. 

WRITFIL contains the address of another 278 byte file buffer area in memory. This is the file buffer 
area used by FDOS to write programs in response to the SAVE command. Any time that the user 
is not actually performing a SAVE, the WRITFIL buffer can be used as a file buffer area by the 
user’s program. 

DAYOM contains the address of the first of a pair of bytes in memory. The first byte contains the 
current day of the month in BCD, from 1 to 31H. The least significant four bits of the second byte 
contain the current month, from 01 (January) to OCH (December). The most significant four bits 
of the second byte contain the current year, from 0 signifying 1975 to OFH signifying 1991. This 
two byte value corresponds to whatever the user entered in response to the FDOS DATE? interro- 
gation at system load time. . 

TXTPNT contains the address of a two byte pointer. This pointer points to an entry in the TXTIN 
buffer which is filled by the TXTIN routine and emptied by the TI routine. The text buffer starts 
with the first byte after the two byte pointer. See Appendix N for further details on this buffer 
and its use. 

LSTERR contains the address of a single byte of memory. Any time that FDOS types an error out 
to the console in the form of: 


ERROR XX 


the value XX is stored in the byte of memory pointed to by the address in LSTERR where XX is a hexa- 
decimal number. By examining this byte, the user’s software can always determine the last error (LSTERR) 
which occurred. By storing a zero in this byte initially and then periodically reexamining this byte, the 
user’s software can detect any errors that occur. 
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APPENDIX C: The PIP Utility Program 


PIP is a utility program used under the control of FDOS. Its purpose is to provide the user with many 
of the useful commands that large operating systems often include, without being restricted to the 4 K size 
of the FDOS main module. 

A brief summary of the PIP commands: 


*COPY filel FROM file2,file3,.... 
*DELETE file1,file2,file3,.... 
*DIRECTORY:1 

*EXIT 

*FREE:1 

*LIST:L file 

*PUNCH file 

*READ file 

*RENAME file1 TO file2 
*RUN file 

*TRACE file 


Description of the PIP commands, with examples: 


*COPY ABLE FROM BOB 


This command will create a file named ABLE. This new file will contain exactly the same data as was 
contained in BOB. An error message will be typed out if BOB does not exist or if ABLE already exists. 


*COPY CHUCK.VV:1 FROM DANDY,EASY:2,FOX:0 


This command creates a file named CHUCK.VV on disk 1. The contents of CHUCK.VV will be exactly 
the contents of the file DANDY on disk 0, followed by the contents of the file EASY on disk 2, followed 
by the contents of the file FOX on disk 0. This is an example of how COPY can be used to concatenate or 


string together several files. 


*DELETE GORRIL.LA:1 


The file titled GORRIL.LA on disk 1 will be removed, and the data blocks that were used by GORRIL.LA 
will be made available to any new files which are created. If no such file as GORRIL.LA exists, then an error 


message will be typed out. 
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*DELETE HELENA:0,IVAN,JEANNE:1 


This command will delete three files: HELENA and IVAN on disk 0 and JEANNE on disk 1. If any one 
of these files does not exist, then an error message will be printed out and PIP will continue to delete the 


other files. 
*DIRECTORY 

This command will type the directory of disk 0 out onto the console. 
*DIRECTORY:L 


This command will type out the directory of disk 0 on the user’s list device. 


*DIRECTORY:L:1 
*DIRECTORY:1:L 


Either of these commands will type out the directory of disk 1 onto the user’s list device. 
*EXIT 

Causes a return to FDOS, but PIP remains in memory. 
*FREE 


This command will cause the number of free blocks (disk blocks not currently used by any file) on 
disk 0 to be printed on the console. 


*FREE:2 

This causes the number of free blocks on disk 2 to be printed on the console. 
*LIST KENTWO:1 

The file named KENTWO on disk 1 will be typed on the console. ASCII 09 characters (horizontal tab) 
will be expanded to multiples of eight columns. If the user types any key on the console, the listing will 
pause until a second key is hit (any key may be used). If aControl-C (*C) is typed, the listing aborts and 
control returns to PIP. If the file KENTWO does not exist, an error message will be printed on the console. 


*LIST:L LYNN 


The listing of LYNN from disk 0 will go to the user’s list device. Tabs, pauses, and Control-C’s are han- 
dled as above. 


*PUNCH MICHAL.TAT:2 


The user’s punch device is sent sixty nulls (a leader), the contents of MICHAL.TAT from disk 2, and 
sixty more nulls (a trailer). If the file MICHAL.TAT does not exist, an error message will be printed on the 
console, and no tape will be punched. 


*READ NVALUE 


A file named NVALUE is created. The contents of this file are read in from the user’s reader device. 
The file is closed after the end of input (end of tape) is found. If the file NVALUE already exists, an error 
message will be typed on the console. 


*RENAME OWEN:1 TO PUPIL:1 


The file named OWEN on disk 1 is renamed to PUPIL. If OWEN:1 does not exist, or if PUPIL:1 already 
exists, an error message will be printed and OWEN will not be renamed. 


*RUN BASIC:1 


This command returns the user to FDOS and causes the BASIC file from disk 1 to be run. This is exactly 
equivalent to a PIP command of EXIT followed by the FDOS command RUN BASIC:1. If the BASIC file 
does not exist, or is not an executable file, then an error message is typed and control returns to FDOS. 


* TRACE SUNNY 


The file named SUNNY on disk 0 will be traced block by block on the disk. As each block is read, six 
bytes of data are typed in hexadecimal format onto the console. These bytes are the track and sector of 
the reverse link, the track and sector of this block, and the track and sector of the forward link. If the file 


SUNNY does not exist, an error message will be typed on the console. 


Listings 


The source code of PIP follows. PIP was written with all FDOS references made via the MODCAL 


routine. Refer to Pass 10 for a full description of the MODCAL routine and its use. 


0000 


0020 
004D 
0008 


0008 
0008 


DooOo 


OOCF 
OICF 
O2CF 
03CF 
O4CF 
OSCF 
O6CF 
O7CF 
O8CF 
O9CF 
OACF 
OBCF 
OCCF 
ODCF 
OECF 
OFCF 
\OCF 
VICF 
12CF 
13CF 
14CF 
15CF 
16CF 
\7CF 


C388D0 


ae ee 


MINI 


BLOCKS 
TRACKS 
DRIVES 


BLOCKS 
TRACKS 
DRIVES 


FDOS 


TITLE % K2 PIP VERSION 1.6 (C) MARCH 1977, Ke B. WELLES’ 


TITLE 


DATE 


K2PIP 


THIS PROGRAM IS USED WITH FDOS TO DO DELETES, DIRECTORIES, COPIES 
AND RENAMES. 


11-MAY- 78 


AUTHOR KENNEIH B WELLES 


$ THIS IS THE CONDITIONAL DIRECTIVE THAT CAUSES PIP TO ASSEMBLE FOR 
$ EITHER A MINIATURE OR A LARGE FLOPPY DISK. 


EQU 


IF 
EQU 
EQU 
EQU 
ENDIF 


IF 
EQU 
EQu 
EQU 
ENDIF 


ORG 
JMP 


EQu 


ie) ASSEMBLE FOR A LARGE FLOPPY DISK 


MINI sMINIDRIVES 
16 
35 
3 


NOT MINI sREGULAR DRIVES 
32 
17 
8 


8 
ODO88H sJUMP TO THE MODCAL ROUTINE IN FDOS 


ODOOOH $FD0S START ADDRESS 


STHE FOLLOWING DEFINITIONS ARE THE UARS TO BE CALLED VIA MODCAL 


BEGIN 
CI 

RI 

co 

PO 

LO 
CSTS 
RESTRT 
INIT 
FDREAD 
FOWRT 
BYTIN 
BYTOT 
BLKIN 
BLKOT 
RNDOT 
OPNIN 
QPNOT 
CLSOT 
FILNAM 
LOKFIL 
TXTYP 
TI 
TXTIN 


EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 


OCFH 

1CFH 

2CFH 

3CFH 

4CFH 

5CFH 

6CFH 

7CFH 

&8CFH 

9CFH 

OACFH 

OBCFH 

OCCFH 

ODCFH 

OECFH ] 
OFCFH ) 
10CFH / 
11CFH 

12CFH 

1 3CFH 

| 4CFH 

15CFH 

10CFH 

1 7CFH 


71 


72 


DELETE EQU 
RENAME EQU 
MEMCHK EQU 
RNDIN EQu 
REDFIL EQU 
WRIFIL EQU 
DAYOM = EQU 
TXTPNT EQU 
LSTERR EQU 
CR EQU 
LF EQU 
TAB EQU 
ORG 
CFO? DW 
ORG 
219000 PIPSTs LXI 
CFI5 DW 
.CFO8 PIRRST® DW 
214600 LxI 
CFIS DW 
CF17 Dw 
CFI6 PIPRis DW 
CAIEOO JZ 
FAI500 JM 
47 MOV 
CFI16 DW 
4F MOV 
CFI6 DW 
57 MOV 
215900 LXI 
1EOB MVI 
7E ROUTLPs MOY 
23 INX 
B8 CMP 
C24900 JNZ 
MOV 
23 INX 
CMP 
C24A00 JNZ 
7E MOV 
23 INX 
BA CMP 
C24B00 JNZ 
5E MOV 
23 INX 
66 MOV 
6B MOV 
E9 PCHL 
23 ERI INX 
23 ER28 INX 
23 ER38 INX 
23 INX 
| DCR 
C23200 JNZ 
21A900 LX! 
CFIS DW 
C31000 JMP 
434F50 ROUTBL: DB 
DI04 Dw 
44454C DB 
A805 DW 
444952 DB 
C401 Dw 
455849 DB 
7406 DA 
465245 DB 
F803 DW 
4C4953 DB 
1A06 DW 
50554E DB 
A106 DW 
524541 DB 
86U6 DW 
52454E DB 
5E05 DW 
52554E DB 
7BU6 DW 
545241 DB 
5904 D 
ROUTNDs 
ODOA3830 PIPSGN® ULB 
38302050 
49502056 
45525349 
4F4E2031 


INIT $MOVE ALL DISKS TQ TRACK O AT THE START OF EACH 


PIPRI s*SKIP ANY LEADING SPACES 
PIPRST %GQ TO BEGINING IF AN EMPTY LINE APPEARS 


B,A 
TI 
C,A 
TI 
DA s$PUT THE FIRST 3 LETTERS OF COMMAND INTO BCD 
H,ROUTBL SROUTINE TABLE 
E, (ROUTND-ROUTBL) /5 
A,M 
4H 
B 
ERI 
AM 
c 
Ek2 
A,M 
H 
1) 
ER3 
E,M $TO GET HERE, IT HAD TO MATCH, GET LO ADDR 
H 
H,M 
L,E tHL HAS ROUTINE ADDRESS 
$GO TO THE ROUTINE 
. SCORRECT THE NUMBER OF OFFSETS 
4H 
H $M IS NEXT ENTRY NOW 
E sLAST ENTRY ?? 


ROUTLP sNOPE 
H,NOFN $sYEP 


PIPST $START ALL OVER AGAIN 
“COPY = sCOPY 


PIPCOP 

“DEL? sDLETE 
DLETE 

“DIRY = sDIRECTORY 
PIPDIR 

“EXIY sEXIT 
EXIT 

¢ FRE? FREE BLOCKS 
FREEB 

“LIS? $LIST 
LIST 

“PUNY = $PUNCH 
PUNCH 

4 REAY sREAD 
READ 

“REN?  $RENAME 
RNAME 

“RUN? = SRUN 
RUN 

“TRAY = s TRACE 
TRACE ; 


CR,LF,“8080 PIP VERSION 1.%, 7674128 


2EB6 

2020204C 
494E4B20 
20202042 
4C4F434B 
2020204C 
494E4B0D 


4C45204E 
41404520 
20202020 
20444154 
45202020 
204C454E 
4754480D 
OAQDOA 


2044454C 
45544544 
ODOA 


21100) 
CFIS 
C31500 


212301 
CFI5 
C31500 


210800 
CFI5S 
C31500 


CDF 701 
(3202 


CO4A02 
CAD601 
CD9702 
C3CA01 
ODO AAA 
4E4F2053 
55434820 
46.554E43 
54494FCE 
20204652 
45452042 
4C4F434B 
530D8A 
49404045 
47414C20 
46494045 
20535045 
43494649 
43415449 
4FCE 
4552524F 
5220494E 
2046494C 
4520544F 
20434F50 
592C2046 
494C4520 
434C4F53 
45442050 
52454D41 
54555245 


ACD9 
4E4F2053 
55434820 
46494045 
20455849 
5354D3 
54484953 
20464946 
4520414C 
52454144 
59204558 
495354D3 


46494045 TRCHEDs 


204E414D 
45205245 
56455253 
45204355 
5252454E 
5420464F 
52574152 
440D0A 

20202020 
20202020 


DIRHEDs 


DIRND# 
DLTDs 


DLNDs 
NOTHER# 


YESHER® 


ILLFSs 


PIPDIR4 
c 


PIPDI8 


ASTs 
NOFNS 


FRBLK® 


IFS3 


ERCND# 


NSFEs 


TRAEs 


DB 


DB 


DB 


DB 


DB 


DB 


DB 


DB 


13,10,7FILE NAME DATE LENGTH’ ,13,10,13,10 


¢ DELETED’ ,.13,10 


H,NSFE 
TXTyP 
PLPRST 
H,TFAE 
TXTYP 
PIPRST 
H,IFS 
TXTYP 
PIPRST 


GETSW $GET ALL SWITCHES (DISK 1, LIST prices ETC) 
STDIR  $sSTART THE DIRECTORY ON THE DIS 


GETENT $GET ONE ENTRY 

PIPD2 sIF LAST ENTRY ALREADY GOTTEN, QUIT Loop 
PUTENT $PUT ONE ENTRY INTO THE BUFFER 

PIPDI $LOOP FOR ALL ENTRIES 

CR,LF,7#%+128 

“NO SUCH FUNCTIO¥ , “N%+1 28 


¢ FREE BLOCKS ,Ck,LF+1 28 


“ILLEGAL FILE SPECIFICATIO¥ ,“N“+1 28 


“ERROR IN FILE TO Copy, FILE CLOSED PREMATUREL? , “Y/ +1 28 


“NO SUCH FILE EXIST’, ’S7+128 


“THIS FILE ALREADY EXIST’, 574128 


“FILE NAME REVERSE CURRENT FORWARD’ ,!3,10 


{Y LINK BLOCK LINK’, 13,10+128 


73 


74 


mak THE V\C 
J(LE* O2eK 200207 GETENT! 


O1D6 CDFDO2 =PIPD2! CALL PUTTIT sPUT QUT THE TITLE AND SET FOR ENTRY RETRIEVAL 


O1D9 CAFIOI JZ PIPD4 NO ENTRIES, DON’T TYPE 
O1DC CFU6 PIPD3! OW CsTS tHAS A KEY BEEN HIT? 
OIDE B7 ORA A : 

O1DF CAEBO) JZ PIPD5  $sNOPE, SKIP AHEAD 

O1E2 CFO! DW cl sYEP, IS IT A *C? 

O14 eee Cpl oe er és ae ' 

oles ctor ba aie ere SaaeE PAR Arr ANOTHER CHARACTER 
OJEB CDI1003.  PLPDSs CALL OUTENT sQUTPUT ONE ENTRY 

OIEE DADCO! Jc PIPD3  sLOOP UNTIL ALL ENTRIES ARE DONE 
OIF! CD7D03 PIPD4! CALL  FREPUT ‘$LIST NUMBER OF FREE BLOCKS LEFT 
O1F4 C31500 JMP PIPRST $ALL DONE, RETURN TO PROGRAM 
O1F7 3E00 GETSW! MYI A,0 #SET THE DEFAULT CONDITIONS 

OIF9 32FD06 STA WODEV — §CONSOLE . DEVICE 

O1FC 320007 STA REDDEV sDISK O 

OIFF CFI6 GETSIs DN TI sGET THE NEXT LETTER 
020) F8 RM $NO SWITCH 

0202 C8 RZ $NO SWITCH 

0203 FE3A cpl aa sSWITHC? 

0205 C2FFO) JINZ GETS! $sNOT YET, TRY AGAIN 

0208 CFI6 DW TI sYES, WHICH SWITCH? 
020A F8 RM t ILLEGAL 

020B C8 RZ # ILLEGAL 

020C FE4C CPI L? sLIST? 

020E C21902 JNZ GETS2 sNOPE 

0211 3E0! MI A,I +YEP 

0213 32FD06 STA WODEV sINDICATE LIST DEVICE 

0216 C3FFO! JMP GETS! = sAND LOOK FOR ANY MORE SWITCHES 
0219 FESO GETS2s CPI ops $PUNCH? 

021B C22602 JNZ GETS3  sNOPE 

O21E 3E02 MVI A,2 sYEP 

0220 32FD06 STA WODEY  sINDICATE PUNCH DEVICE 

0223 C3FFO! JMP GETS! $LOOK FOR ANY MORE SWITCHES 
0226 D630 GETS3s SUI 70" tDRIVE #? 

0228 F8 RM §NO, ILLEGAL 

0229 FEO8 CPI DRIVES sMAYBE 

022B FO RP #NO, ILLEGAL 

022C 320007 STA REDDEV ‘YES, SET UP DRIVE # 

022F C3FFO) JMP GETS! sAND LOOK FOR MORE SWITCHES 
0232 210202 STDIR: LXI H,202H $sTRACK 2 SECTOR 2 

0235 221207 SHLD REDT RK+4 

0238 210407 LXI H, REDBUF 

023B CFIB DW RNDIN sREAD IN FIRST BLOCK OF THE DIRECTORY 
023D 210907 LX1 H,REDDAT-16 SRESET THE POINTER 

0240 220207 SHLD  RBPNT  $AND STORE IT 

0243 214409 XI H,DIRBUF sCLEAR THE DIRECTORY BUFFER 
0246 224209 SL DRBFND ‘BY RESETING THE POINTER 


THE DATA POINTER 
sDE IS THE FIRST OFLO VALUE 


sHL<DE IS LEGAL 


024D 110908 
0250 COF702 


1 ELSE, NEXT BLOCK, TRACK=2 
WN y STA REDT RK+4 
9 4 a ig I) LDA REDTRne! sNEXT SECTOR IS THIS SECTOR+¢2 
(QZ \(P ANI BLOCKS~2 8CHECK FOR EODIRECTORY 
P 0262 321307 sSET UP FOR NEXT BLOCK 
0265 © sRETURN ON EOD 
09 21040 H, REDBUF 
9 LF 1B RNDIN sREAD IN THE NEXT BLOCK 
0265 210907 H,REDOAT-16 $HL POINTS TO NEXT POSSIBLE ENTRY 
KO 
pi iy 026E 111000 GETI# LXI D,16 sUP THE POINTER BY ONE ENTRY 
gots 0271 19 DAD D SHLSHL+16 
> < 0272 220207 SHLD RBPNT STORE THE UPDATED POINTER 
wy 0275 7E MOM A.M sCHECK THE FIRST BYTE OF THE ENTRY 
‘ QV, 0276 B7 ORA A 
AL 0277 FA4A02 JM GETENT ‘sCANCELED ENTRY, TRY THE NEXT 
f 027A C8 RZ NO MORE ENTRIES, RETURN 
0278 F5 PUSH PSW ~—_—-$ELSE, SAVE THE FIRST ENTRY AND NON-ZERQ STATUS 
27C 113609 LXI D,BUFENT sDE POINTS [O ENTRY BUFFER 
027F 0609 MVI B,9 $MOYE 9 BYTES RIGHT OFF THE BAT 
0281 7E GET2s MOV A.M 
0282 12 STAX D 
0283 23 INX 4H 
0284 13 INX D 
0285 05 DCR B 
0286 C28102 JINZ GET2 
0289 23 INX H 
028A 23 INX H sSKIP 2 BYTES 


0288 0603 


028D 7E 
O28E 12 
O28F 23 
0290 13 
0291 05 
0292 C28D02 


0295 Fl 
0296 C9 


0297 114409 
O29A 2A4209 
029D CDF702 
O2A0 DAC902 
02A3 CDE402 
O2A6 F2B102 
Q2A9 210C00 
O2AC 19 

O2AD EB 

Q2AE C39A02 


Q2B! 2A4209 
02B4 E5 
02B5 010C00 
02B8 09 
Q2B9 4D 
Q2BA 44 
O2BB E1 


O2BC CDF702 
O2BF CACCO2 
O2C2 0B 
02C3 2B 
02C4 7E 
02C5 02 
02C6 C3BC02 


02C9 2A4209 
O2CC 113609 
O2CF 060C 
02D! IA 
O2D2 77 
02D3 23 
02D4 13 
02D5 05 
02D6 C2vI02 


O2D9 2A4209 
Q2DC 110C00 
O2DF 19 
O2EO 224209 
O2E3 C9 


O2E4 D5 
O2E5 213609 
O2E8 0609 


O2EA IA 
O2EB 96 
O2EC C2F502 
O2EF 23 
O2FO 13 
Q2F1 05 
O2F2 C2EA02 
O2F5 DI 
O2F6 C9 


O2FD 0623 

Q2FF 217F0) 
0302 CD8003 
0305 eneee? 


0309 214409 
030C COF702 
O30F C9 


0310 0606 
0312 CD8003 
0315 OE2E 
0317 C5706 
031A 0603 
031C C08003 


GET3:3 


PUTENTs 
PUTI8 


PUTHERs 


PUT2s 


PUTLSTs 
MOV DONS 


PUT38 


ALPHA’ 


ALPHI 8 


ALPH28 


COMPAR® 


PUTTITs 


QUTENTS 


B,3 §AND MOVE 3 MORE 

A.M 

D 

H 

b 

B 

GET3 

PSW SSTATUS SHOWS A SUCCESSFUL ENTRY RETRIEVAL 
D,DIRBUF *DE=FIRST ENTRY 


DRBFND $HL*AFTER LAST ENTRY 

COMPAR $%AFTER LAST - FIRST 

PUTLST $PUT IT AT THE END OF THE LIST 
ALPHA $LIST-NEW 

PUTHER $PUT IT HERE IF LIST>NEW 


H, 12 
D 
sD=D+12 
PUTI #LOOP UNTIL THE RIGHT PLACE IS FOUND 


DRBFNU =$HL*0LD END 


H $SAVE THE OLD END 
B,l2 

B #tHL=NEW END 

CyL 

B,H sBC=NEW END 

H $HL*0LD END 


COMPAR $sSOURCE QF MOVE = ENTRY POINT 
MOVDON $WHEN EQUAL, THE MOVE IS DONE 


B *DECR DEST 

H $DECR SOURCE 

ALM sGET FROM SOURCE 

B sSEND TO DEST 

PUT2 

DRBFND $LOAD HL WITH ENTRY POINT 
D, BUFENT $DE POINTS [0 BUFFER AREA 
B,12 MOVE 12 BYTES 

D 

MAA 

H 

D 

B 

PUT3 

DRBFND $sGET THE OLD END 

D,!2 


D tHL=HL+12 
DRBFND $sSTORE THE NEW END 


D #SAVE D=START OF LIST ENTRY 
H, BUFENT HL HAS NEW TO BE ENTERED 
B,9 SCOMPARE FIRST 9 LETTERS 
D sA=LIST ENTRY 
u 
ALPH2 
H 
D 
B 
ALPHI 
D sRESTORE DE=START 
sRETURN FLAGS SHOW LIST-NEW 
A,H tHL-DE 
D 
A,L 
E 


B,DIRND-DIRHED ‘$LENGTH OF TITLE To TYPE 


Hy DIRHED 

WLST TYPE THE TITLE 

DRBFND $SET UP TO TYPE THE DIRECTORY 
DE®END 

H, DIRBUF SHL IS START 


COMPAR $IF DEsHL, NO ENTRIES ON THIS DISK 


B,6 sTYPE OUT FIRST 6 CHARACTERS 


WLST 

C,%.% = sD0T 

WO 

B,3 sTYPE OUT 3 CHAR EXTENSION 
WLST 


75 


76 


EOOF 


DOUTI 8 


FREPUTs 
WLSTs 


WASCs 


WHEXs 


WCRLF3 


W4DIGs 
W4DI18 


Cc,” @ 


WO #SPACE SPACE 
wo 
A,M $A=DOM*0FLO 
PSW §SAVE OFLO 
3FH 
WASC $TYPE OUT BCD DATE 
C,’-% — §DASH 
WO 
H 
A.M $A=YEAR/MONTH 
H +SAVE H 
OFH tA=l-12 MONTH 
H,MONTHS=3 
H sGET HL TO POINT TO THE MONTH 
H 
H 
A 
DouT! 
B,3 
WLST = $TYPE OUT THE MONTH 
C,’-% — $DASH 
WO 
H sRECALL H 
AyM $A©YR/MN 
OFH tA=YEAR-1975 BINARY 
r) 
tA=YEAR-1975 BCD 
75H 
$A=YEAR-1900 BCD 
WASC sTYPE QUT THE YEAR 
£L,% ¢ 
WO sSPACE SPACE 
WO 
H 
EM $E=LENGTH IN BLOCKS 
PSW SRECALL OFLO 
3 §A=LENGTH/256 
D,A $DE*LENGTH 0-1023 
W4DIG STYPE QUT THE BLOCK COUNT 
WCRLF $TYPE OUT CR, LF 
H SPOINTS TO THE NEXT ENTRY 
DRBFND $sBEYOND LAST ENTRY 
COMPAR $§POINT-END 
SRETURN TO LOOP 
FREI § TEMPORARY 
tis sGET CHARACTER TO TYPE 
7FH sCLEAR MSB 
CA sPUT THE LETTER OUT 
WO 
B sCOQUNT IT 
WLST #DONE? 
sYEP 
PSW sSAVE LSN 
WHEX sTYPE OUT MSN 
PSW sRECALL LSN 
OFH 80-15 
70" 80-9 ASCII 
C,A 
WO 
C,13 sCR, LF TO WO 
WO 
c,10 
WO 
B,O 3BC DEC#DE BIN 
. §DE=02 
DONDIG $sYEP, DONE 
A,C SNOPE, UP DEC 


03B3 C601 
03B5 27 
03BS 4F 
03B7 78 
03B8 CEO0O 
O3BA 27 
O3BB 47 
O3BC 1B 
03BD C3AD03 


03CO 59 
03C!I 50 
03C2 0600 
03C4 7A 
03C5 OF 
03C6 OF 
03C7 OF 
03C8 OF 
03C9 CDDFO3 
O3CC 7A 
03CD CDDFO3 
03D0 7B 
03D! OF 
03D2 OF 
03D3 OF 
03D4 OF 
03D5 CDvFO3 
03b8 061 
O3DA 7B 
03DB CDDFO3 
O3DE C9 


O3DF E60F 
O3E] C2r903 
O3E4 05 
03E5 04 
O3E6 CAF203 
O3E9 C63U 
QO3EB 4F 
O3EC C05706 
O3EF 0601 
O3F1 CY 


O3F2 OF20 
03F4 CD5706 
O3F7 CY 


03F8 CDF701 


O3FB 210200 
O3FE 221207 
0401 210407 
0404 CFIB 
0406 110000 
0409 211807 
040C OE94 


O40E 0608 
0410 7E 
0411 23 


Oal2 OF 
0413 DAI 704 
0416 13 
0417 05 
OA18 C21204 


041B OD 
O41C C20E04 


O41F CO9FO3 


0422 CDAA03 
0425 21B900 
0428 O60F 


042A CD8003 


042D C31500 


0430 OEOD 
0432 CFO3 
0434 OEOA 
0436 CFO3 
0438 C9 


0439 CS 
OA3A FS 
043B OF 
043C OF 
0430 OF 


W4ASC8 


W4AP3 


MOV 


ANI 
JNZ 


ADI 
MOV 
CALL 
MVI 
RET 


SUPRES# MVI 


FREEBs 


} 
| fen 


CALL 
RET 


CALL 


I 
a 
LXI 


sDOWN DEC 
#LOOP UNTIL THE END 


+DE=BC 
#B=0 SUPPRESS 0S 
sTYPE DIGIT 1 


' sDIGIT 2 


sbDIGIT 3 
FORCE AT LEAST 1} PRINT 
sDIGIT 4 


sJUST 0-9 
sIF > O THEN PRINI 


$B=0? 
sYES, SUPRESS THE CHAR 
$NO, PRINT 


sPRINT IT 
§NOQ MORE SUPPRESS 


— 


TRACK 2 SECTOR O 


F 
sBRING IN THE BIT MAP 


IBLOCK COUNT = O 


THE BIT MAP 


LX1_____b,O_ 

‘LXI H, REDUAT+2 STAR 

MVI C, (TRACKS~3)#(BLOCKS/1 Y heel 
— Sor Posty? 


SGET THE DEVICE NUMBER _ 


? 
pb? 


\) 


¥ 


ae 


{ 


y 


> al 
ar Mr? VO 
enue Fre 


|DIR72 MMVI B,8 $8 BIITS/BYTE > 
MOV AyM PONG 
INX H sONE BYTE IN MA? 
IF MIN 
INX H sMINI SKIPS EVERY OTHER BYTE IN BIT MAP TERITORY 
ENDIF 
RRC 
Je DIR9 sIF BIT IS 1, THEN BLOCK IS USED 
INX D tIF BIT IS 0, THEN BLOCK IS FREE, COUNT IT 
DcR B 
JNZ O1R8 
OCR c 
JINZ DIR7 
CALL WCRLF $TYPE OUT A CR, LF 
CALL W4DIG $TYPE OUT DE AS A 4 DIGIT BCD 
LXI H,FRBLK sFREE BLOCK TEXT 
MVI B, IFS-FRBLK 
CALL WLST 
JMP PIPRST 
CRLFs MYI C,CR sTYPE OUT A CR, LF 
DW co 
MVI C,LF 
DW co 
RET §#CAUSES AUTOMATIC RETURN 
sTHIS ROUTINE TYPES OUT THE 2 DIGIT BCD VALUE INA 
BCDASC! PUSH B 
PUSH PSW 
RRC 
RKC 
RRC 


77 


78 


0459 210407 
Q45C CDE705 
Q45F DAACO! 
0462 213B0! 
0465 CFI5 

0467 210407 
046A CFIO 


046C 210407 
O46F CFOD 
0471 CD3004 


0474 06u9 
0476 210407 


O4A2 CDC304 
04A5 3A1207 
47 


O4BA C36C04 


O4BD COCAO0A 
O4CO COCA04 
04C3 CDCAOA 
04C6 eee 


TYPHEX$ 


Ty2s 


TRACES 


TRIs 


Tk28 


SP33 
SP2s 
SPls 


SPACEs 


PIPCUPs 


CoPis 


TYPHEX ‘$TYPE OUT A HEX DIGIT 
PSW 
PSW RECALL LSN 


H, REDBUF sTHIS IS THE INPUT BUFFER 
NAMGET sSET UP THE FILE NAME TO TRACE 
NOTHER sTEMP EXIT 

H,TRCHED 

TXTYP 

H, REDBUF 

OPNIN 


H, REDBUF $GET THE NEXT BLOCK 
BLKIN 
CRLF $SET UP THE NEXT LINE 


B,9 sTYPE 9 LETTERS 
H, REUBUF 


CM sTYPE THE 9 LETTER NAME 

co 

H 

B 

Tre 

REDBUF +12 

Sp3 sTYPE 3 SPACES AND A HEX BYTE 


REDBUF+13 
SPI sTYPE | SPACE AND A HEX BYTE 


REDBUF+ II 
SPI 


REDBUF+14 

Sp3 

REDBUF+15 

SP 

ay aaa sCHECK THE FORWARD LINK 


B 

REDBUF+15 

B s1S IT ZERO? 
PIPRST $YEP, QUIT TRACING 


A sLETTER STRUCK?? 
TRI SNOPE, CONTINUE 


cI SWAIT FOR ANOTHER LETTER TO CONTINUE 


SPACE $TYPE A SPACE 


CR $CHECK FOR INPUT STREAM ERRORS 
PIPCoP 

H, WRTBUF 

FILNAM 

ILLFS sERROR IN FILE NAME SPEC 


LOKFIL sNUST NOT BE PRESENT 
anak sBUT IT IS 


CR 
ILLFS 


O52A 3A0107 
052D FE2C 
O52F CA3C05 
0532 FE20 
0534 C25605 
0537 CFl6 
0539 C32D05 


053C 210407 
O53F CFI3 
0541 320107 
0544 DASIO5 
0547 CFI4 
0549 DADSI05 
054C CFIO 
O54E C31905 


0551 21£200 
0554 CFI5 
0556 211D08 
0559 CFI2 
055B C31500 


O55E CFI6 
0560 FABCO] 
0563 C25E05 
0566 210407 
0569 CFI3 
056B DASCOI 
O56E CFI6 
0570 FABCO! 
0573 FED4 
0575 CAs005 
0578 FE20 
O57A CAGEOS 
057D C3BC0) 


0580 CFI6 
0582 FABCO! 
0585 C28005 
0588 211D08 
058B CFI3 
058D DABCO! 
0590 CFI4 
0592 D2B40) 
0595 210407 
0598 CFI4 
059A DAACOI 
O59D 210407 
O5A0 111D08 
O5A3 CFI9 
05a5 C31500 


O5A8 COF701 
O5AB 211008 


0Q5C5 DAACO! 
05C8 CFIS 


Cop2s 


COP38 


EoOcopYs 
Cap4s 


MORCOPS 


ERRCLSs 


COPCLSs 


RNAME 8 


RENI8 


REN2# 


DLETEs 
DLETIs 


ILLFS  $sERROR IN OUTPUT FILE SpEC 


TRMNAT $STORE THE TERM 

TRANAT INATION CHARACTER 
NOTHER $00PS, FILE DOESNT 

OPNIN. SEXISES, GPEN FOR INGGre 

H, WRTBUF 

OPNOT — 80PEN FOR OUTPUT 


H, REDBUF 
BYTIN 
EQCOPY 41S IT THE END OF THE BUFFER? 
H, WRTBUF 
BYTOT 
COP3 CONTINUE, 1 IN, 1 OUT 
TRWNAT SRECALL THE TERMINATION CHARACTER 
° 
MORCOP 1, MEANS, MORE FILES To Copy, CONCATENATE 


COPCLS 


H, REDBUF 

FILNAM ‘$sGET THE NEXT INPUT BUFFER 
TRMNAT $STORE THE TERMINAL CHARACTER 
ERRCLS $sERROR, CLOSE AS IS 

LOKFIL 

ERRCLS $NON-EXISTANT, CLOSE AS IS 
OPNIN 

COP3 sOPEN AND COPY 


H,ERCND 

TXTYP sLATER 
H,WRTBUF 

CLSOT $sCLOSE THE OUTPUT FILE 
PIPRST sAND GET ANOTHER COMMAND 


Tl 
ILLFS $sPREMATURE END (OF LINE 
RNAME —=$WAIT FOR SPACE 


FILNAM $GET FILE NAME 
ILLFS  $ERR IN SPEC 


Tl sFIND A T FOR TO 
ILLFS sPREEMY 

dt Sal sGIMME A T 

REN2 tYEP, GO ON 

Md #SKIP SPACES 
RENI 

ILLFS 

Tl 


ILLFS  $sPREEMY 
REN2 sWAIT FOR SPACE 


H, WRTBUF sGET THE NEW NAME 

FILNAM 

ILLFS  sERR IN SPEC 

LOKFIL $15 IT PRESENT?? 

YESHER ‘sYEP, SHOULDN/T BE 

H, REDBUF 

LOKFIL 81S IT PRESENT 

NOTHER. sNOPE, SHOULD BE!! 

H, REDBUF $HL POINTS TO THE OLD NAME 
D,WRTBUF $DE POINTS TO THE NEW NAME 


RENAME $sPERFORM THE FDOS RENAME FUNCTION 
PIPRST sTEMPQRARY END, RNAME NOT ENABLED 


GETSW $GET THE DEVICE TO TYPE ON 
H,WRTBUF 
FILNAM $GET THE NAME OF THE FILE TO DLETE 


TRMNAT 
PSW $SAVE THE GOOD OR BAD SPEC INDICATOR 


H, WRTBUF $TYPE OUT THE FILE NAME, FIRST 9 CHARS 
B,9 


WLST 
H, WRTBUF 
PSW_- SRESTORE THE HL AND FLAGS 


ILLFS ¢BAD SPEC 
LOKFIL 41S THE NAME PRESENT?? 


NOTHER $NOPE, ERROR! 
DELETE sYEP, *DLETE USING THE FDOS FUNCTION 


79 


80 


O5CA 21A201 
O5CD 060A 
OS5CF CD8003 
O5D2 3A0107 
05D5 FE2C 
05D7 CAABOS 
O5DA FE20 
O5DC C2E405 
OSDF CFI6 


OS5E4 C31500 


O61A CDF701 
061D 210407 
0620 CDECO5 
0623 DAACO! 
0626 CFIO 
0628 0600 


062A CFOB 
062C DAI500 
Q62F FEUD 


0657 3AFD06 
Q65A E6U1 
O65C CA6206 
O65F CFO5 


066E C26506 
067! C32A06 


0674 CFI6 


DLET28 


DLET3s 
NAMGETs 
NAMGI 8 


HEX NUM3 


HEXNIS 


FORBITs 


FORI8 


LIST 
WOUT8 


LISLOPs 


EOL8 


NTEOL8 


WILOPs 


WOs 


wCos 


TBULATs 


EXITs 


H,DLTD 
B, DLNU-DLTD 


DLET! $IF ENDED WITH A COMMA, DELETE THE NEXT FILE ALSO 
a.% tIF ENDED WITH A SPACE, 

DLET3 $sNOT SPACE, QUIT 

TI tYES SPACE, TRY AGAIN 

DLET2 

PIPRST sTEMPORARY 


TI 

NAMGET 
FILNAM 
LOKFIL 


H,0 
FORBIT 


GETSW s$GET THE OUTPUT DEVICE 


H,REUBUF 

NAMG I 

NOTHER $&TEMP ERR REIURN 

OPNIN 

B,O *B=CHAR COUNT 

BYTIN 

PIPRST $END OF FILE 

Ck 

ih $CR QR LF ENDS LINE 

NTEOL 

B,-! tAFTER A CR OR LF, B20 

TAB 

TBULAT $8GQ HERE IF A TAB IS FOUND 
C,A tELSE TYPE THE ACTUAL CHAR 
WO sLIST THE OUTPUT 


B 
CsTS IS A KEY DEPRESSED?? 
A 
LISLOP $NOPE! 
Cl 
sIS THE KEY HIT A “C ? 


3 

PIPRST 

cI WAIT FOR ANOTHER KEY STROKE 
LISLopP 


‘me WHAT IS THE WO DEVICE 
Hy sIF ZERO, CO IS THE OUTPUT 


co 


a ¢ $0ON A TAB, FILL TO OMOD8 WITH SPACES 
8 sAT LEAST ONE SPACE 


A,B 

7 MOD 8 
TBULAL 

LISLOp 


TI 


0676 F27406 JP EXIT 


0679 CFO7 DW RESTRT ‘QUIT AFTER EMPTYING THE COMMAND BUFFER 
067B CF&4 RUNS OW TXTPNT $GET THE 

067D 5D NOY EsL iReaL THE ADDRESS OF TEXT POINTER IN HL 
O67E 54 MOV D,H 

a 1 ae 

6 INX D sDE=POINTER#+2 2S 

eal 75 may ME Re2aSTART OF BUFFER 

eee 4 INX H 

68. MOV M.D #POINTER IS NOW AT THE START! 

0684 CFO7 DW RESTRT SAND PERFORM THE FUNCTION !! 
0686 211D08 READs LXI H, WRIBUF ‘CHECK THE NAME 

0689 CDE705 CALL NAMGET 

O68C D2B401 JNC YESHER ‘sALREADY PRESENT, QUIT 

va a ea ee QPNOT = $OPEN THIS FILE FOR OUTPUT 

ADIs DW RI #READ EXACTLY 1! CHAR FROM THE READER 

0693 DA9COS Jc READ2 sCARRY BIT SAYS WE ARE DONE 
0696 4F MOV CA 

0697 CFOC DW BYTOT 
0699 C39106 JMP READI 
Q69C .CFI2 READ2: DW CLSOT = s$CLOSE THE OUTPUT FILE 
Q69E C31500 JMP PIPRST 
O6Al 210407 PUNCHs LXI H, REDBUF $GET THE INPUT FILE NAME TO PUNC 
Q6A4 CDE705 CALL NAMGET 
O6A7 DAACOI Jc NOTHER #NOT PRESENT, QUIT 
O6AA CFIO DW OPNIN  $PRESENT, OPEN FOR INPUT 
OaaC CDCO006 CALL LEADER sPUNC A LEADER 
O6AF CFOB PUNCI8 DW BYTIN 
06B! DABAOS Jc PUNC2 = =$CARRY IS EOF 
O6B4 4F MOV C,A 
Q6B5 CFO04 DW PO SPUNC A CHAR 
06B7 C3AFO6 JMP PUNCI 
O6BA CDCO06 = PUNC28 CALL LEADER 
O6BD C31500 JMP PIPRSI $PUNC A LEADER (TRAILER) AND RETURN 
06CO 163C LEADER? MVI D,60 #60 CHARS PEK LEADER 
06C2 OEVO MVI c,0 sALL 07S 
06C4 CFO4 LEADIs DW PO 
06C6 15 DCR D 
06C7 C2C406 JNZ LEADI 
O6CA C9 RET 
O06CB 455252 DB “ ERR 


O6CE 4A414E46 MONTHS? DB 
O6D2 45424041 
06D6 52415052 
O6DA 4D41594A DB 
O6DE 554E4AD5 
O6E2 4C41 5547 
06E6 5345504F bb 
O6EA 43544E4F 
O6EE 56444543 


4 JAN’, 7 FEB’ »“MAR’, “APR? 


“MAY? , 4 JUN , “JUL? , “AUG? 


4SEPY y40CT?% NOV? , “DEC? 


O6F2 45525245 DB ERK’, 7 ERR’, “ERR? 
O6F6 52524552 
O6FA 52 
DIRCNTs DB (0) 
OorC 00 TEMP DB VY) $USEFUL FOR TEMPORARY STORAGE 
O6FD 00 WODEVs DB iV) S$QUTPUT DEVICE (LP OR CO) 
O6FE 00 OFLOs DB (¢) 
O6FF 0000 BLKCNT# DB 0,0 
0701 00 TRMNAT: DB 1?) 
0702 0000 RBPNT# DW (0) 
0704 REDBUF® Ds 9 
070D 00 REDDEVs DB t¢) 
O70E REDTRK# DS Wl 
O719 REDDAT® DS 260 
081D WRTBUF® DS 9 
0826 00 WRTDEVs DB ¢) 
0827 WRTTRK* DS Wl 
0632 WRTDAT® DS 260 
0936 BUFENT® DS 12 
0942 4409 DRBFND* DW DIRBUF 
0944 DIRBUF? Ds 2380 LOTSA ROOM? 
0000 END 
ALPH! O2EA ALPH2 O02F5 ALPHA O2E4 AST O0A6 
SCDAS 0A39 BEGIN OOCF BLKCN O6FF BLKIN ODCF 
BLKOT OECF BLOCK 0020 BUFEN 0936 BYTIN OBCF 
BYTOT OCCF Cl OICF CLSOT 12CF co O3CF 
COMPA O2F7 COP! O4EA COP2 OAF6 Cop3 0519 


81 


82 


COPCL 0556 
DAYOM 83CF 
DIR9 O417 
DIRND O1A2 
DLETE O5A8 
DOUTI. 033B 
EQL 0639 
ERCND OOE2 
FUREA O9CF 
FORBI 0606 
FREPU 037D 
GETEN 024A 
GETSW OJF7 
ILLFS 0JBC 
LF 000A 
LOKFI 14CF 
MONTH O6CE 
NAMGE O5E7 
NTEOL 063B 
QUTEN 0310 
PIPD3 O1LC 
PIPRI OOIE 
PO O4CF 
PUT! O29A 
PUTHE 02B1 
READ 0686 
REDDA 0719 
REN! O56E 
RI O2CF 
ROUTB 0059 
SP] 04C3 
STDIR 0232 
TEMP O6FC 
TR2 UATY9 
TRMNA 0701 
TY2 0455 
W4D1 O3AD 
WCRLF O039F 
WODEY O6FD 
WRIDE 0826 
YESHE 01B4 


WRTBU 
WRITR 


Beginning on page 86 is a complete machine readable re i ® 
presentation (PAPERBYTE® bar codes) of th 
object code for Ken Welles’ PIP routine, as assembled in the listing beginning below. This bar . ane 
arnt ~ eso loader format, in which each bar code frame (one line of bars running from top 
to bottom of the page) contains a two byte address followed by data which is loaded i i 
starting at that address. : Serena oe 
The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 
listing does not correspond directly to the variable length records of the bar codes, but in general use a 
fixed length of 16 data bytes. 


0008 C3 88 DO 1B 
0000 CF 07 D6 
0010 21 90 00 CF 15 CF 08 21 A6 00 CF 15 CF 17 CF 16 E2 
0020 CA 1E 00 FA 15 00 47 CF 16 4F CF 16 57 21 59 00 28 
0030 1E 0B 7E 23 B8 C2 49 00 7E 23 B9 C2 4A 00 7E 23 94 
0040 BA C2 4B 00 SE 23 66 6B E9 23 23 23 23 1D C2 32 9F 
0050 00 21 A9 00 CF 15 C3 10 00 43 4F 50 DI 04 44 45 Cl 
0060 4C A8 05 44 49 52 C4 01 45 58 49 74 06 46 52 45 DA 
0070 F8 03 4C 49 53 1A 06 50 55 4E Al 06 52 45 41 86 FB 
0080 06 52 45 4E SE 05 52 55 4E 7B 06 54 52 41 59 04 08 
0090 OD 0A 38 30 38 30 20 50 49 50 20 56 45 52 53 49 99 
OOAO 4F 4E 20.31 2E B6 OD OA AA 4E 4F 20 53 55 43 48 83 
OOBO 20 46 55 4E 43 54 49 4F CE 20 20 46 52 45 45 20 88 
00CO 42 4C 4F 43 4B 53 OD 8A 49 4C 4C 45 47 41 4C 20 6F 
00ODO 46 49 4C 45 20 53 50 45 43 49 46 49 43 41 54 49 64 
OOEO 4F CE 45 52 52 4F 52 20 49 4E 20 46 49 4C 45 20 BE 
OOFO 54 4F 20 43 4F 50 59 2C 20 46 49 4C 45 20 43 4C 19 
0100 4F 53 45 44 20 50 52 45 4D 41 54 55 52 45 4C D9 25 
0110 4E 4F 20 53 55 43 48 20 46 49 4C 45 20 45 58 49 36 
0120 53 54 D3 54 48 49 53 20 46 49 4C 45 20 41 4C 52 Fl 
0130 45 41 44 59 20 45 58 49 53 54 D3 46 49 4C 45 20 E3 
0140 4E 41 4D 45 20 52 45 56 45 52 53 45 20 43 55 52 67 
0150 52 45 4E 54 20 46 4F 52 57 41 52 44 OD 0A 20 20 C5 
0160 20 20 20 20 20 20 20 20 20 4C 49 4E 4B 20 20 20 AE 
0170 20 42 4C 4F 43 4B 20 20 20 4C 49 4E 4B OD 8A 0D BD 
0180 OA 46 49 4C 45 20 4E 41 4D 45 20 20 20 20 20 20 2B 
0190 44 41 54 45 20 20 20 20 4C 45 4E 47 54 48 OD 0A 717 
01A0 OD OA 20 44 45 4C 45 54 45 44 OD 0A 21 10 O1 CF 46 
01B0 15 C3 15 00 21 23 O1 CF 15 C3 15 00 21 C8 00 CF A6 
01CO 15 C3 15 00 CD F7 01 CD 32 02 CD 4A 02 CA D6 01 6D 
01D0 CD 97 02 C3 CA 01 CD FD 02 CA FI 01 CF 06 B7 CA D2 
01E0 EB 01 CF 01 FE 03 CA 15 00 CF 01 CD 10 03 DA DC 02 
01FO 01 CD 7D 03 C3 15 00 3E 00 32 FD 06 32 0D 07 CF AE 
0200 16 F8 C8 FE 3A C2 FF 01 CF 16 F8 C8 FE 4C C2 19 9A 
0210 02 3E 01 32 FD 06 C3 FF 01 FE 50 C2 26 02 3E 02 Bl 
0220 32 FD 06 C3 FF 01 D6 30 F8 FE 08 FO 32 0D 07 C3 F5 
0230 FF 01 21 02 02 22 12 07 21 04 07 CF 1B 21 09 07 A7 
0240 22 02 07 21 44 09 22 42 09 C9 2A 02 07 11 09 08 24 
0250 CD F7 02 DA 6E 02 3E 02 32 12 07 3A OF 07 C6 02 B3 


0270 
0280 
0290 
02A0 
02B0 
02C0 
02D0 
02E0 
02F0 
0300 
0310 
0320 
0330 
0340 
0350 
0360 
0370 
0380 
0390 
03A0 
03B0 
03C0 
03D0 
03E0 
03F0 
0400 
0410 
0420 
0430 
0440 
0450 
0460 
0470 
0480 
0490 
04A0 
04B0 
04C0 
04D0 
04E0 
04F0 
0500 
0510 
0520 
0530 
0540 
0550 
0560 
0570 
0580 
0590 
05A0 
05B0 
05C0 
05D0 
05E0 
05F0 
0600 
0610 
0620 


00 
09 
13 
DA 
02 
cc 
0C 
22 
13 
TE 
06 
20 
CD 
3B 
OF 
57 
CD 
TE 
OF 
0D 
Co 
59 
7B 
OF 
01 
07 
WE 
oF 
OE 
4A 
FA 
AC 
0D 
04 
CD 
13 
CF 
CD 
C9 
CF 
01 
F6 
AC 
05 
3C 
13 
05 
FA 
FA 
CF 
CF 
11 
32 
DA 
80 
16 
C9 
06 
F2 
CD 


19 
TE 
05 
C9 
2A 
02 

1A 

42 
05 
01 
06 
CD 
57 
03 
OF 
06 
9F 
23 
OF 
CD 
03 
50 
OF 
C2 
C9 
21 
23 
03 
0D 
04 
55 
01 

CD 
3A 
BD 
07 
06 
CA 
CF 

13 
FE 
04 
01 
4F 
05 
32 
21 
BC 
BC 
16 
14 
1D 
01 
BC 
03 

C3 
21 
D2 
16 
EC 


22 

12 
C2 
02 
42 
0B 
717 
09 
C2 
CD 
CD 
57 
06 
06 
E6 
cD 
03 
E6 
cD 
57 
719 
06 
OF 
E9 
0E 
04 
OF 
CD 
CF 
Fl 
04 
21 
30 
10 
04 
CD 
B7 
04 
16 
DA 
46 
21 
CF 
21 
FE 
01 
E2 
01 
01 
FA 
D2 
08 
07 
01 
3A 
DS 
00 
F8 
06 
05 


07 
13 
02 
E4 
ES 
TE 
13 
DS 
02 
03 
03 
CD 
TE 
CD 
C6 
06 
EB 
4F 
03 
OE 
01 
7A 
OF 
05 
CD 
CF 
17 
03 
OE 
CD 
07 
01 
06 
CD 
OF 
04 
6C 
CA 
0D 
01 
EA 
07 
21 
08 
C2 
DA 
CF 
SE 
54 
01 
01 
19 
21 
14 
07 
C3 
CD 
B7 
07 
AC 


TE 
05 
Fl 
02 
01 
02 
05 
21 
D1 
2A 
OE 
57 
ES 
80 
00 
23 
2A 
CD 
Fl 
0A 
27 
OF 
CD 
04 
57 
1B 
04 
21 
0A 
4A 
4F 
CF 
09 
BD 
07 
3A 
04 
04 
CA 
CF 
04 
CF 
1D 
CF 
56 
51 
15 
05 
CA 
C2 
21 
C3 
1D 
DA 


FE | 


15 
06 
C9 
D8 
01 


FA 
81 
11 
Bl 
00 
BC 
D1 
09 
7C 
09 
CD 
TE 
OF 
OE 
C6 
Fl 
09 
06 
OF 
57 
78 
OF 
03 
F2 
C9 
00 
05 
00 
03 
Fl 
03 
21 
04 
3A 
C3 
07 
01 
39 
01 
D2 
16 
DA 
CF 
C3 
CF 
CF 
1D 
04 
05 
05 
07 
00 
06 
01 
CA 
CF 
D8 
16 
0A 
10 


4A 
02 
44 
02 
09 
02 
02 
06 
BA 
EB 
57 
FS 
21 
2D 
75 
07 
EB 
05 
C6 
06 
CE 
OF 
06 
03 
CD 
00 
C2 
06 
C9 
Cl 
C9 
04 
07 
11 
04 
47 
CF 
04 
FE 
B4 
FE 
BC 
11 
19 
16 
14 
08 
07 
FE 
21 
CF 
CD 
09 
CF 
AB 
16 
29 
D6 
B7 
06 


02 

23 

09 

21 

4D 
2A 
2A 
09 

co 
21 

06 
E6 
CB 
CD 
27 

07 
CD 
C2 
30 
C9 

00 
CD 
01 

C6 

F7 
21 

12 
OF 
CS 
C9 
21 

07 
4E 
07 
3A 
3A 
01 

C9 
20 
01 

0D 
01 

21 

05 
C3 

DA 
CF 
CF 
20 
1D 
14 
F7 
CD 
18 
05 
C2 
29 
30 
C9 

00 


C8 
23 
2A 
Te 
44 
42 
42 
1A 
7D 
44 
06 
3F 
06 
57 
CD 
E6 
F7 
80 
4F 
01 
27 
DF 
7B 
30 
01 
1B 
04 
CD 
FS 
E6 
04 
CF 
CF 
CD 
12 
13 
C3 
FS 
C2 
CF 
CA 
32 
04 
3A 
2D 
51 
12 
13 
CA 
08 
DA 
01 
80 
21 
FE 
E7 
29 
D8 
CD 
CF 


36 
TE 
CD 
EB 
F7 
36 
oc 
F5 
06 
F7 
80 
03 
23 
TE 
OE 
CD 
C3 
F5 
06 
7B 
C3 
CD 
03 
57 
00 
94 
OE 
C3 
OF 
30 
E7 
04 
05 
3A 
BD 
CA 
CD 
CF 
21 
0D 
FE 
CF 
OB 
FE 
04 
10 
00 
01 
C3 
DA 
21 
08 
1D 
06 
E4 
13 
6F 
D8 
21 
15 


06 
23 
02 
9A 
CA 
06 
19 
23 
21 
c9 
OE 
2D 
C2 
OF 
CD 
03 
03 
OF 
OE 
CA 
03 
03 
E6 
06 
12 
08 
CD 
00 
CD 
3A 
DA 
CF 
719 
07 
3A 
00 
04 
Fl 
08 
BC 
C2 
DA 
2A 
CA 
CF 
19 
16 
16 
01 
01 
07 
13 
Fl 
CD 
CF 
14 
06 
06 
07 
FE 


0630 
0640 
0650 
0660 
0670 
0680 
0690 
06A0 
06B0 
06CO0 
06D0 
06E0 
06FO 
0700 
070D 
0826 
0942 


0D 
4F 
15 
05 
06 
13 

11 

00 
OB 
16 
4E 
4A 
45 

00 
00 
00 
44 


CA 
CD 
00 
C9 
C3 
73 
CF 
21 

DA 
3C 
46 
55 
43 
00 


09 


39 
57 
CF 
CF 
2A 
23 
02 
04 
BA 
OE 
45 
4C 
45 
00 


06 
06 
01 
03 
06 
72 
DA 
07 
06 
00 
42 
41 
52 
00 


FE 
04 
C3 
c9 
CF 
CF 
9C 
cD 
4F 
CF 
4D 
55 
52 


OA C2 


CF 
2A 
OE 
16 
07 
06 
E7 
CF 
04 
41 
47 
45 


06 
06 
20 
F2 
21 
4F 
05 
04 
15 
52 
53 
52 


3B 
B7 
3A 
CD 
714 
1D 
CF 
DA 
C3 
C2 
41 
45 
S2 


06 
CA 
FD 
57 
06 
08 
0c 
AC 
AF 
C4 
50 
50 
45 


06 
2A 
06 
06 
CF 
CD 
C3 
01 
06 
06 
52 
4F 
52 


FF 
06 
E6 
04 
07 
E7 
91 
CF 
CD 
C9 
4D 
43 
52 


FE 
CF 
01 
78 
CF 
05 
06 
10 
Co 
45 
41 
54 
00 


09 CA 


01 

CA 
E6 
84 
D2 
CF 
CD 
06 
52 
59 
4E 
00 


FE 
62 
07 
5D 
B4 
12 
co 
C3 
52 
4A 
4F 
00 


65 
03 
06 
C2 
54 
01 
C3 
06 
15 
4A 
55 
56 
00 


06 
CA 
CF 
65 
13 
CF 
15 
CF 
00 
41 
4E 
44 
00 
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onmm 
on-k 
onoct 
orkbeo 
otrun 
otr0Ow 
orac 
orgtwo 
Ootan 
ornw 
orton 
ornn 
ort 
o+ng 
oto 
otom 
onmnmw 
omodc 
omUnw 
oman 
omag 
OMON 
omrw 
omen 
ontw 
ome 


omnnnm 


o~nrn 
omc 
onrn 
ome 
orn 
o~wt 
o~r~m 
conn 
one 
o~o 
oucn 
ows 
ovcnm 
ove 
oucn 
cvrtr 
cocom 
ecwvn 
coc 
ovo 
onan 
ono 
onr 
onw 
onn 
ont 
onm 
oun 
on 


ono 


Carn 
cone 
orca 
ockm 
ocOouw 
ocUudc 
cocan 
owt 
cowed 
oo~rn 
cocoon 


oon 


onan 
oa$e 
oan 
one 
oan 
oat 
onam 
can 
oo; 
oac 
coon 
ooo 00 
oom 
onoec 
oon 
owt 
oor 
CON 
ocoo- 


cowoeo 
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APPENDIX D: Formatting New Disks 


Before a new disk can be used with K2FDOS it must be formatted. The FORMAT program listed in this 
appendix will perform this function in about one minute. To use FORMAT, you must do the following: 


1) Load K2FDOS. FDOS may be loaded by the disk boot loader using paper tape or cassette, or FDOS may 
be resident in read only memory. 

2) Load and run FORMAT. FORMAT may be run from disk, or it may be loaded from cassette or paper 
tape. 

3) FORMAT prints out: 


FAST FORMAT ROUTINE V1.3 INSERT DESIRED DISK INTO DRIVEO 
THIS WILL WIPE OUT DISK 0, ARE YOU VERY SURE? 


4) Insert the disk to be formatted into drive 0, making sure that the disk is not write protected. 
5) Type YES<cr> in response to step 3. FORMAT will exercise disk drive zero for about one minute, then 
print: 


THIS DISK HAS BEEN SUCCESSFULLY FORMATTED 
and FORMAT will return to FDOS. 


The FORMAT routine will not disturb tracks 0 or 1 where FDOS resides (SYSGEN loads these tracks; 
see Appendix E). All data blocks on tracks 2 through 76 will be filled with zeroes, except for the sync byte, 
the track and sector identifier, and the check sum bytes. This initializes the directory to empty and the bit 
map to indicate that all blocks are free. Since all blocks have zero forward and reverse links, all blocks will 
appear unlinked. 

If the FORMAT routine cannot format a data track because of disk damage, FORMAT will print the 
message: 


A HARD WRITE ERROR OCCURRED ON TRACK x 


where x is the number of the damaged track. 
The user is strongly advised against using disks that do not FORMAT properly, since a damaged disk is 
likely to lose data at the most inconvenient times. 


Listings 


The following listing is the source code for FORMAT. In operation, FORMAT calculates the 16 data 
blocks (each 313 bytes long) to be written onto a disk track. All 16 blocks are then written out during 
one revolution of the disk. FORMAT then verifies the data written out by reading all 16 blocks during one 
revolution and comparing the 280 bytes from sync through check sum to the data stored in memory (from 
which the track was just written). If the data does not match exactly, three more write-verify cycles are 
performed before an error is declared. If the data agrees exactly, then the disk head is moved in one track, 
the data blocks are calculated for this new track, and the cycle is repeated. 
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90 


0070 
0073 


0075 
0076 
0077 
0078 


007B 
OO7E 


0080 
008! 
0082 
0085 
0086 


C300D0 


21601 
CD73D0 
CO79D0 
C0 76D0 
FES9 

C200D0 


214903 
0600 
0E10 


113901 


70 
23 
1B 
78 
B2 
C22B00 


OD 


C22800 


215903 
11390) 
OEIO 
0681 


70 
19 
OD 
C24100 


216503 
113901 
OEIO 
0600 


70 
19 
04 
04 
oD 
C25100 


3£00 
324703 
D3F3 
CDC502 


CDDFO2 
CDDFO2 


215903 
0E10 


E5 
cS 
cD8D02 
23 
73 


TITLE 
AUTHOR K.B. WELLES 


DATE 


“FORMAT VERSION 1.3 (C) MAY 19.77 K.B.WELLESY 


14-FEB-78 


* USE THE FULL SIZED DISK 


MINI 


$ THESE 
FDOS 
TXTIN 
TI 


TXTYP 


START8 


-DLOPs 


CLoPs 


‘SLOPs 


BLOPs 


WLOPs 


TLOaps 


CKLops 


PURPOSE OF THIS ROUTINE IS TO QUICKLY FORMAT DISK TRACKS 2 THROUGH 76 


oO 
ODOOOH $sRETURN TO FDOS 


10H 
H,WARN sISSUE THE WARNING 
X 


FDOS SRETURN TO FDOS IF ANYTHING BUT A “"Y® TYPED 


$SET UP ALL THE LEADING ZEROS 
SAND ALL TRAILING ZEROS 
sAND ALL THE DATA ZEROS 


H,SYNI sSET UP ALL SYNCH BYTES 


$SECTOR OF CURRENT BLOCK 
8SET UP SECTORS OR ALL BLOCKS 


sINITIALIZE THE DRIVES 


sTRACK | 


sMOVE IN ONE TRACK 
#PUT THIS TRACK NUMBER IN ALL SECTORS 


$GET THE CRC FOR ALL SECTORS 
¢DE GETS THE CRC 


EQU 0 
ARE THE ONLY FDOS ROUSINES USED 
EQU 0D 000H 
EQU FuOS+ 79H 
EQU FDOS+* 76H 
EQU FD0S¢73H 
ORG 

JMP 

ORG 

LXI 

CALL =‘ TXTYP 
CALL = IXTIN 
CALL TI 

cpl “ye 

JNZ 

LXI H,SYNI-16 
MI B,O 

MVI C,BLOCKS 
LXI D, SYN2-SYNJ 
MoV MB 

INX mi 

DCX D 

MOV AE 

ORA D 

JNZ cLop 

DCR Ps 

JNZ DLP 

LXI 

LXI D,SYN2-SYNI 
MYI C, BLOCKS 
MYI B,SYNCB 
MOV MB 

DAD D 

DCR Cc 

JNZ SLOP 

LXI H,SYNI +12 
LXI D, SYN2-SYNI 
MVI C, BLOCKS 
MVI B,O 

MOV MB 

DAD D 

INR B 

INR P) 

DCR Cc 

JNZ BLOP 

MYI A,0 

STA FDBUF 
OUT FUOUT 
CALL _GIRKO 
CALL — TRAKIN 
CALL — TRAKIN 
LXI H,SYNI#11 
LDA TRAKNO 
MoV BA 

LXI D,SYN2-SYNI 
MVI C,BLOCKS 
Moy MB 

DAD D 

DCR Cc 

JNZ TLap 

LXI H, SYNI 
MVI C, BLOCKS 
PUSH =H 

PUSH B 

CALL = CHKA36 
INX Hq 

MOV MAE 


foRooRo Lolo Molen >) 
MOQOFON Vw 


OF 


21DB01 
CD 73D0 
C3U00D0 


CD1403 


3A4703 


WILOPs 


SELF3 


LPs 


OKYDOK8 


TRKWRT# 


ALOPS 


BLKWRT# 


WRTLOPS 


LDA 
Crl 
JNZ 


LXI 
CALL 
JMP 


o 


» SYN2-SYNI 


folui oi 4-5 + + 


A,4 sTRY 4 TIMES TO WRITE THIS TRACK 


TRKWRT sWRITE THE TRACK 

TRKCHK READ AND VERIFY THE TRACK 
OKYDOK ¢1F CORRECT, GO ON 
piSeray sELSE, TRY AGAIN 


H,WTER sTYPE OUT THE ERROR MESSAGE 
TRAKNO sTYPE OUT THE TRACK NUMBER 


Fbos SERROR RETURN TO FDOS 

TRAKNO #$CORRECT WRITE, CHECK FOR DISK DONE 
WLOP 8GQ ON TO THE NEXT TRACK 

H,FMTD sTELL [HE USER THAT IT WORKED 

FDOS sAND RETURN TQ FDOS 


WRITE THIS TRACK ONCE (ALL SECTORS) 
HEDLOD sLOAD THE HEAD 
INDXGT #GET THE INDEX 
H,SYNI-16 
C, BLOCKS 
BLKWRT WRITE 16 BLOCKS 
LD, SYN2-SYNI 
D 


Cc 
ALOP 


B SWRITE ONE BLOCK 


H 

D, LNBUF +X TRA*24 
FDBUF 

WRIGAT 

C,A 

HEDLOD 

SCTGET 


NOT FUREST 
FDOUT 


FDOTWI 
A,M 
FOWRI1 
H 


D 
A,D 
E 


WRTLOP 
FLBUF 

NOT WRKTGAT 
FDOUT 
FUBUF 

H 

B 


92 


0130 CD1403 TRKCHKs CALL 
0133 CD2503 CALL 
0136 215903 LXI 
0139 OEI0 MVI 
013B E5 CHLaps PUSH 
013C CS PUSH 
013D 111701 LXI 
0140 C0540) CALL 
0143 Cl PoP 
0144 El PoP 
0145 ©2520) JNZ 
0148 113901 XI 
OMB 19 DAD 
o14c OD DCR 
014D C2380! JNZ 
0150 AF XRA 
0151 & RET 
0152 37 CHERR? STC 
0153 C9 RET 
0154 CD1403  BLKCHKs CALL 
0157 CD2D03 CALL 
O15A 3E81 MVI 
015C D3F2 OUT 
O1SE DBF3 IN 
0160 DBF4 VERIFY8 IN 
0162 DBFO IN 
0164 BE CMP 
0165 ©O RNZ 
0166 23 INX 
0167 1B DCX 
0168 7A Mav 
0169 B3 ORA 
016A C2600! JNZ 
O16D © RET 
O.16E 0D0A4641 WARNS DB 
0172 53542046 

0176 4F524D41 

O17A 5420524F 

OI7E 5554494E 

0182 45202056 

0186 312E332C 

O.18A 20494E>3 

O18E 455254 

0191 20444553 DB 
0195 49524544 

0199 20444953 

O19D 4B20494E 

OIAl 544F2044 

O1AS 52495645 

O1A9 2030 

O1AB 0D0A5448 DB 
O1AF 49532057 

01B3 494C4C20 

01B7 57495045 

O1BB 204F5554 

OIBF 20444953 

01C3 4B20302C 

O1C7 20415245 

OCB 20594F55 

OICF 20564552 

0.1D3 59205355 

O1D7 52453F 

OIDA AO DB 
©.1DB OD0A5448 FMTD: DB 
OIDF 49532044 

0.1E3 49534820 

O1E7 48415320 

OIEB 4245454E 

OIEF 20535543 

O1F3 43455353 

OIF7 46554C4C 

OIFB 5920464F 

OFF 52404154 

0203 544544A1 

0207 ODOA4I20 WIERs DB 
020B 48415244 

020F 20575249 

0213 54452045 

0217 52524F52 

021B 204F4343 

O21F 55525245 

0223 44204F4E 

0227 20545241 

022B 434BA0 

022E 30300D4A TKTPs DB 


¢VERIFY THIS TRACK AGAINST MEMORY 


HEDLOD #LOAD THE HEAD 
INDXGT *GET THE INDEX PULSE 


H,SYNI 
C,BLOCKS 


H #CHECK EACH OF THE BLOCKS 
B 

D,279 

BLKCHK 


B 
H 


CHERR 
D,SYN2-SYN! 
D 


c 
CHLOP 
A 


$SET THE CARRY IF THE TRACK DOES NOT VERIFY 


HEDLOD sCHECK ONE BLOCK 
SCTGET 

A, SYNCB 

SRTRSS 

SRTRR 


FDINWT SVERIFY THIS DATA AGAINST RAM 
peed 


13,10,“FAST FORMAT ROUTINE, Y1.3, INSERT? 


¢ DESIRED DISK INTO DRIVE 0” 


13,10,7THIS WILL WIPE OUT DISK O, ARE YOU VERY SURE?4 


¢ 44128 
13,10,*THIS DISK HAS BEEN SUCCESSFULLY FORMATTED? , 7 !4+1 28 


13,10,7A HARD WRITE ERROR OCCURRED ON TRACK’, * .2+128 


700,13, 10*128 


ey 


0232 OD0A5345 
0236 43544F52 
023A 20455252 
023E 4F522046 
0242 4F554E44 
0246 20204449 
024A 534B2053 
O24E 50454544 
0252 20544F4F 
0256 20464153 
025A 542C204F 
O25E 5220434C 
0262 4F434B 
Q265 ODOA5350 
0269 45454420 
026D 544F4F20 
0271. 534C4F57 
0275 2020484) 
0279 52445741 
027D 52452045 
Q281 52524F52 
0285 OD8A 


OOFO 
OOF | 
OOF2 
OOF3 
OOF4 


OQOFO 
OOFI 
QOF2 
OOF3 
OOF4 
OOFS 
OOF6 


0001 
0002 
0004 
FFFB 
0008 
0010 
FFEF 


0001 
0002 
0004 
0008 
0010 
0020 


0081 


0100 
0016 
Ol7 


0287 7C 
0288 92 
0289 CO 
028A 7D 
0288 93 
O28C C9 


028D 011601 
0290 110000 
0293 7E 
0294 & 


SCLGs 


* THESE 


INPORT 
OTPORT 
BLOCKS 
TRACKS 


INPORT 
OTPORT 
BLOCKS 
TRACKS 


FDRED 
FDSTAT 
SRTSWE 
SRTRR 
FDINWT 


FDARIT 
SRTIFS 
SRTRSS 
FDOUT 

FDOTAT 
LOADHD 
HDUNLD 


$ THESE 
WCSEL 
FUREST 
DIRIN 
DIROT 
WRIGAT 
STEPP 
STEPM 


$ THESE 
TRKZRO 
UNSAFE 
FDRDY 
SCTR 
INDX 
HEADLD 


+ THESE 
SYNCB 
LNBUF 
XTRA 
LN2SNC 


DB 


DB 


13,10,“SECTOR ERROR FOUND, DISK SPEED Too FAST, OR CLOCK’ 


13,10,“SPEED TOO SLOW, HARDWARE ERROR’, 13,.10+128 


ARE THE FLOPPY DRIVE I-0 ROUTINES 


21-APR-77 

IF NOT MINI tFOR THE FULL SIZE INTERFACE, 

EQu OFOH 

EQU OFOH 

EQU 16 

EQU 71 

ENDIF 

IF MINI — $FOR THE MINI, 

EQu OE8H  sTHE INPORT CLUSTER 

EQU OESH § 4THE QUIPORT CLUSTER 

EQU 8 

EQU = 35 

ENDIF 

EQU INPORT sDATA FROM THE FLOPPY 

EQU INPORT#1 SSTATUS BITS OF THE FLOPPY 

EQU INPORT#2 $READ THE SRT STATUS WORD 

EQU INPORT+3 $ INPUTTING THIS RESETS THE USRT TO LOOK 
EQU INPORT+4 SKLUGE To SYNCHRONIZE TO 32 MICRSECS 
EQU OTPORE sDATA TO BE WRITTEN TO THE FLOPPY 

EQUu OTPORT#1 SPORT OF [HE DEFAULT CHARACTER 
EQU OTPORT+2 

EQU OTPORT+3 $SEND SIGNALS TO THE FLOPPY 

EQU OTPORT+4 $SYNC TO 32 MICROSECS 

EQU OTPORT#5 STHIS COMMANDS LOADS THE HEAD FOR 3. SECONDS 
EQU OTPORT+6 $THIS FORCES AN IMMEDIATE HEAD UNLOAD 
ARE SIGNALS To FDOUT (DIRECT FLOPPY CONTROLS) 

EQU i tl=TRACK 0-43, O=TRACK 44-76 

EQU 2 4USE TO RESET A FILE UNSAFE CONDITION 
EQU 4 $LOGICAL OR FOR IN TRACK 

EQU NOT DIRIN SAND FOR OUT TRACK 

EQU 100 sLOGICAL OR TO START A WRITE 

EQU 200 sLOGICAL OR TO START A STEP PULSE 

EQU NOT STEPP $LOGICAL AND TO STOP THE PULSE 
ARE THE DIRECT STATUS LINES OF THE FLOPPY (IN FDSTAT) 

EQU 1 

EQU 2 

EQU 4 

EQU 8 

EQU 10H 

EQU 20H 

ARE VARIOUS PARAMETERS 

EQU 81H $THIS IS IHE SYNC BYTE FOR START OF TRACK 
EQU 256 SLENGTH OF THE BUFFER 

EQU 22 SEXTRA BYTES FOR HOUSEKEEPING 

EQU LNBUF+XTRA+! | sDISTANCE OF SYNC TO CHECKSUM 


tTHIS ROUTINE COMPARES HL TO DE 


COMPAR! MOV AyH 
SUB D 
RNZ 
MOV A,L 
SUB E 
RET 
§ THIS ROUTINE DOES A 16 BIT CRC (FROM THE INTEL USERS LIBRARY) 
CHK4362 LXI ByLNBUF#K TRA 
2 LX 
CHELOPs ov AwM 1GET THE BYTE TO SUM 
PUSH H 


93 


94 


0306 


0309 
030A 
030B 
030C 
030F 
0310 
0313 


CDEEO2 
DBFI 
E6U1 
C2D102 
324603 
(7 


214603 


324703 
C3FA02 


> 214603 


35 
3A4703 
E6FB 
324703 
FO1U 
D3F3 


> E6EF 


D3F3 
CDv603 
cy 


GTRKOs CALL 


TRZLPs CALL 


STA 
NODSK® ReT 


sSAVE ALL THE REGS. 


- 
CHKLOP) =$NEXT BYTE IF NOT YET DONE 


‘1RAKIN sFIND IFRACK ZERO 
TRAKIN 

TRAKIN 

TRAKIN 

TRAKOT 

FDSTAT 

TRKZRO 

TRZLP 

TRAKNO 


STHESE ROUTINES MOVE 1HE TRANK 


sTHESE ROUTINES MOVE THE HEAD IN (TOWARDS HUB) OR QUT (TOWARDS CIRCUMFER 


8ONE LKACK FOX EACH CALL, CALL LADIS IU MILSECS 


TRAKINe LKI 
INR 
LDA 
ORI 
SIA 
JMP 

TRAKOT® LXI 
DCR 
LDA 
ANI 
SIA 

TRAKMV8 OXI 
QUT 
ANI 
OUT 
CALL 
ReT 


H,ITRKAKNO 

M sCOUNT UP ONE [RACK 
FDBUF 

DIRIN 

FDBUF 

TRAKMV 

H, TRAKNO 

M sCOUNT DOWN THE TRACK 
FUBUF 

DIROT sCLEAR FOR AN QUT MOVE 
FUBUF sSAVE IT 

S1LEPP $SET THE STEP BIT 
FDOUT sAND THE START BIL 
STEPM sCLEAR STEP BIT 

FDOUT 

TENMIL) swWAIL TEN NILSECS 


FIHIS ROUTINE IS JUST A SOFTWARE 10MS WAIT 


TENMILs 


x 
TMLPs) DCX 


MINI 
B,60U0Q 


NOT MINI 
B, 20000 


0314 
0316 
0318 
O31A 


0318 
O31E 
0321 


0349 
0359 
035A 
0472 


0482 
0492 
0493 
O5AB 


O5BB 
O5CB 
o5cCc 
O6E4 


O6F4 
0704 
0705 
081D 


082D 
083D 
083E 
0956 


0966 
0976 
0977 
OA8F 


OA9F 


OAAF 
OABO 


DBF! 
E620 
D3F5 
co 


Cb0603 
00603 
(00603 


$THIS ROUTINE LOADS THE HEAD AND WAITS 30 MS FOR SETTLING 


HEDLODs 


LOLPs 


INDXGTs 


SCTGETs 


SCTLPs 


ERLONG® 


RETRY 
TRAKNOs 
FDBUF # 
LSTBYT# 


SYN28 


SYN3! 


SYN4s 


SYN5s 


SYN63 


SYN78 


IN FDSTAT 
ANI HEADLUD 
QUT LOADHD 


IF NOT MINI 
CALL TENMIL 
CALL TENMIL 
CALL TENMIL 


IF MINI 
MYI D,33 
CALL TENMIL 
DCR vb 

JNZ LDLP 


QUT LOADHD 


RET 
IN FDSTAT 
ANI INDX 


IN FDSTAT 
ANI SCTR 
Jz ERLONG 
IN FDSTAT 
ANI SCTR 
RZ 

JMP SCTLP 
LXI 4, SCLG 
CALE TXTYP 
JMP Fboos 
DB 4 

DB oO 

DB te) 

DB ie) 


BYTE 0-8 
BYTE 9 
BYTE 10,11 
BYTE 12,13 
BYTE 14,15 
BYTE 16-19 
BYTE 20 
BYTE 21-276 
BYTE 278-279 
Ds 16 
Ds | 
DS 280 
DS 16 
DS 16 
DS | 
DS 280 
DS 16 
DS 16 
DS | 
DS 280 
Ds 16 
DS 16 
Ds | 
DS 280 
DS 16 
D> 16 
Ds | 
Do 280 
Ds 16 
Ds 16 
Do | 
DS 280 
DS 16 
Ds 16 
DS | 
Ds 280 


$GET THE INDEX PULSE 


sGET THE SECTOR PULSE 


sIT TOOK TOO LONG TO GET THE SECTOR PULSE 


ALL DATA FILES, LINKED OR CONTIGUOUS, SHALL HAVE THE FOLLOWING FORMATS 


FILNAM.EXT, 9 BYTES ASCII FILE NAME ON EACH BLOCK 
DEVICE NUMBER, IGNORE 

CURRENT TRACK (3-76), SECTOR (0-303 EVEN) OF THIS BLOCK 
TRACK SECTOR OF PREVIOUS BLOCK (0,0 IF THIS IS FIRST) 
TRACK SECTOR OF FOLLOWING BLOCK (0,0 IF THIS IS LAST) 
FUTURE USE 

BYTE COUNT OF INCOMPLETE DATA BLOCKS 

256 DATA BYTES 

CYCLIC REDUNDANCY CHECK BYTES 


$16 BYTES OF 0, PREAMBLE 
sTHE SYNCH BYTE 
sTHE DATA BYTES 
$THE POSTAMBLE 


$16 BYTES OF O, PREAMBLE 
sTHE SYNCH BYTE 
tTHE DATA BYTES 
sTHE POSTAMBLE 


$16 BYTES OF 0, PREAMBLE 
sTHE SYNCH BYTE 

sTHE DATA BYTES 

$THE POSTAMBLE 


$16 BYTES OF 0, PREAMBLE 
sTHE SYNCH BYTE 
sTHE DATA BYIES 
#THE POSTAMBLE 


$16 BYTES OF O, PREAMBLE 
$1THE SYNCH BYTE 

sTHE DATA BYTES 

sTHE POSTAMBLE 


316 BYTES OF O, PREAMBLE 
sIHE SYNCH BYTE 
#THE DATA BYTES 
sTHE POSTAMBLE 
$16 BYTES OF 0, PREAMBLE 


THE SYNCH BYTE 
#1HE DATA BYTES 


95 


96 


SYNGS 


SYN9s 


SYNAS 


SYNB8 


SYNCS 


SYND4 


SYNEs 


SYNFs 


SYNOs 


BLKCH 
CHE RR 
CHLOP 
DIRIN 
FDBUF 
FDOUT 
FDARI 
HOUNL 
INDXG 
LOADH 
NODSK 
SCLG 
SELF 
SRTSW 
STE PP 
SYN3 
SYN7 
SYNB 
SYNE 
TKTP 
TRAKI 
TRKCH 
TXTIN 
WARN 
WRTLO 


WCSEL 
WIER 


sTHE POSTAMBLE 


$160 BYTES OF 0, 
‘THE SYNCH BYTE 
sTHE DATA BYLES 
sTHE POSTAMBLE 


816 BYTES OF 0, 
sTHE SYNCH BYTE 
#THE DATA BYTES 
sTHE POSTAMBLE 


$16 BYTES OF O, 
‘THE SYNCH BYTE 
sTHE DATA BYTES 
THE POSTAMBLE 


$16 BYTES OF O, 
sTHE SYNCH BYTE 
THE DATA BYTES 
sTHE POSTAMBLE 


#16 BYTES OF O, 
sTHE SYNCH BYTE 
THE DATA BYTES 
sTHE POSTAMBLE 


416 BYTES OF O, 
sTHE SYNCH BYTE 
sTHE DATA BYTES 
STHE POSTAMBLE 


$16 BYTES OF O, 
sTHE SYNCH BYTE 
THE DATA BYTES 
THE POSTAMBLE 


416 BYTES OF O, 
sTHE SYNCH BYTE 
sTHE DATA BYTES 
*THE POSTAMBLE 


#16 BYTES OF O, 
sTHE SYNCH BYTE 
$THE DATA BYTES 
S$THE POSTAMBLE 


OOFF BLOCK 
028D CHKLO 
0080 CLOP 
FFFB DLOP 
OOF4 FDos 
0004 FDRED 
01DB FURES 
0020 HEDLO 
OOFO LN2SN 
00B3 LSTBY 
0007 OTPOR 
032D SCTLP 
0041 SRTRR 
OOF! START 
15B0 SYNI 
0704 SYN5 
OBES SYN9 
10CC SYNCB 
1477 TENMI 
0075 TMLP 
U2FA TRAKN 
OOE8 TRKZR 
D073 UNSAF 
0001 WLOP 
0207 WTLOP 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


Beginning on page 99 is a complete machine readable representati ® 

object code for Ken Welles’ FORMAT routine, as secinbled in the ten irate ie call Aes 
representation uses the absolute loader format, in which each bar code frame (one line of bars running from 
top to bottom of the page) contains a two byte address followed by data which is loaded in ascending order 
starting at that address. 

The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 


listing does not correspond directly to the variable length records of the bar codes, but i 
t in general 
fixed length of 16 data bytes. lacie: 


0000 C3 00 DO 93 
0010 21 6E 01 CD 73 DO CD 79 DO CD 76 DO FE 59 C2 00 —£E2 
0020 DO 21 49 03 06 00 OE 10 11 39 01 70 23 1B 7B B2 87 
0030 C2 2B 00 OD C2 28 00 21 59 03 11 39 01 0E 10 06 ODO 
0040 81 70 19 OD C2 41 00 21 65 03 11 39 O1 OE 10 06 12 
0050 00 70 19 04 04 OD C2 51 00 3E 00 32 47 03 D3 F3 31 
0060 CD C5 02 CD DF 02 CD DF 02 21 64 03 3A 46 03 47 42 
0070 11 39 01 OE 10 70 19 OD C2 75 00 21 59 03 0E 10. Dt 
0080 E5 C5 CD 8D 02 23 73 23 72 Cl El 11 39 01 19 0D 44 
0090 C2 80 00 3E 04 32 45 03 CD E8 00 CD 30 01 D2 D7’ SA 
O0AO 00 21 45 03 35 C2 98 00 21 07 02 CD 73 DO 3A 46 B2 
00BO 03 47 AF C6 01 27 05 C2 B3 00 47 OF OF OF OF E6' CA 
00CO OF C6 30 32 2E 02 78 E6 OF C6 30 32 2F 02 21 2E = 7C 
00D0 02 CD 73 DO C3 00 DO 3A 46 03 FE 4D C2 66 00 21 BC 
OOEO DB 01 CD 73 DO C3 00 DO CD 14 03 CD 25 03 21 49 C2 
OOFO 03 OE 10 CD FF 00 11 39 01 19 0D C2 F3 00 C9 CS’ Al 
0100 E5 11 2E 01 3A 47 03 F6 08 4F CD 14 03 CD 2D 03 D7 
0110 79 D3 F3 E6 FD D3 F3 D3 F4 7E D3 FO 23 1B 7A B3 SB 
0120 C2 17 01 3A 47 03 E6 F7 D3 F3 32 47 03 El Cl C9 E8 
0130 CD 14 03 CD 25 03 21 59 03 OE 10 E5 C5 11 17 O1 47 
0140 CD 54 01 Cl El C2 52 01 11 39 01 19 OD C2 3B 01 48 
0150 AF C9 37 C9 CD 14 03 CD 2D 03 3E 81 D3 F2 DB F3_ AB 
0160 DB F4 DB FO BE CO 23 1B 7A B3 C2 60 01 C9 OD OA 86 
0170 46 41 53 54 20 46 4F 52 4D 41 54 20 52 4F 55 54 81 
0180 49 4E 45 2C 20 56 31 2E 33 2C 20 49 4E 53 45 52 DD 
0190 54 20 44 45 53 49 52 45 44 20 44 49 53 4B 20 49 28 
O1A0 4E 54 4F 20 44 52 49 56 45 20 30 OD 0A 54 48 49 D7 
01B0 53 20 57 49 4C 4C 20 57 49 50 45 20 4F 55 54 20 38 
01CO 44 49 53 4B 20 30 2C 20 41 52 45 20 59 4F 55 20 DC 
01D0 56 45 52 59 20 53 55 52 45 3F AO OD 0A 54 48 49 80 
O1EO 53 20 44 49 53 4B 20 48 41 53 20 42 45 45 4E 20 F4 
O1FO 53 55 43 43 45 53 53 46 55 4C 4C 59 20 46 4F 52 AC 
0200 4D 41 54 54 45 44 Al OD 0A 41 20 48 41 52 44 20 17 
0210 57 52 49 54 45 20 45 52 52 4F 52 20 4F 43 43 55 7F 
0220 52 52 45 44 20 4F 4E 20 54 52 41 43 4B AO 30 30 7F 
0230 OD 8A OD 0A 53 45 43 54 4F 52 20 45 52 52 4F 52 28 
0240 20 46 4F 55 4E 44 2C 20 44 49 53 4B 20 53 50 45 1B 
0250 45 44 20 54 4F 4F 20 46 41 53 54 2C 20 4F 52 20 F6 
0260 43 4C 4F 43 4B OD 0A 53 50 45 45 44 20 54 4F 4F 06 
0270 20 53 4C 4F 57 2C 20 48 41 52 44 57 41 52 45 20 1F 
0280 45 52 52 4F 52 OD 8A 7C 92 CO 7D 93 C9 O1 16 O1 EO 
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00 00 
6F 79 
OF A8 
C2 93 
CD EE 
03 34 
35 3A 
F3 CD 
0A 03 
CD 06 
CA 3C 
DO C3 


TE 
07 
5F 
02 
02 
3A 
47 
06 
c9 
03 
03 
00 


E5 
E6 
719 
c9 
DB 
47 
03 
03 
DB 
C9 
DB 
DO 


C5 
IF 
A8 
CD 
Fl 
03 
E6 
C9 
Fl 
DB 
Fl 
04 


47 
6F 
E6 
02 
01 
04 
32 
00 
20 
E6 
08 
00 


OF OF 
78 07 
EO AB 
CD DF 
C2 DI 
32 47 
47 03 
04 AF 
D3 FS 
10 C2 
C8 C3 
00 


OF 
E6 
SF 
02 
02 
03 
F6 
0B 
Co 
25 
34 


OF 4F A8 E6 FO 
01 AA AD 57 79 
Cl El 23 OB 78 
CD DF 02 CD DF 
32 46 03 C9 21 
C3 FA 02 21 46 
10 D3 F3 E6 EF 
B9 C2 0A 03 B8 
CD. 06 03 CD 06 
03 C9 DB Fl E6 
03 21 32 02 CD 


34 
47 
3C 
87 
6C 
9D 
BA 
64 
9B 
c9 
AF 
DA 
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APPENDIX E: 
Using the SYSGEN Utility Program 


SYSGEN is a program which stores the contents of a segment of memory onto the disk in one large 
block. The data format of this block is such that the BOOT program (Appendix F) can quickly load this 
data back into memory and run it. 

SYSGEN is used to store a BOOTable copy of FDOS onto track 0 to 1 of the user’s disk. Whenever the 
user makes any changes to FDOS, such as customizing the I/O jump table to the user’s own I/O devices, a 
new copy of FDOS can be stored on the disk with SYSGEN. SYSGEN should also be used whenever the 
user FORMATs a new disk. Note that SYSGEN will write only onto track 0 or track 1. SYSGEN and 
ental programs perform complementary functions, do not interefere with each other, and can be used 
in any order. 


Use of SYSGEN 


To store a copy of FDOS ona disk, perform the following steps: 


1) Load FDOS. Make sure that FDOS is loaded and that the DATE routine is still present (when you 
branch to DOOOH, the console requests the date). FDOS can be loaded by bootstrap from a disk, paper 
tape, or cassette tape. 

2) Customize FDOS. Make whatever changes you wish to customize FDOS to your system (see Appendix 
G). If you are just duplicating FDOS, this step is skipped. 

3) Load and run SYSGEN. Do not enter a date! If you wish to load SYSGEN from the disk, answer the 
DATE? with a $<cr> and then type RUN SYSGEN (this preserves the date function in FDOS). Alter- 
nately you may load SYSGEN from paper tape or cassette. 

4) SYSGEN prints out: 


LOAD THE DESIRED DISK, TYPE “Y” 


5) Load the disk that you wish to SYSGEN into drive 0. This usually will not be the same disk that you 
booted FDOS in from. An unformatted disk may be loaded if desired. 
6) Type, Y<cr>; SYSGEN responds with: 


WHICH TRACK, 0 or 1? 


7) Enter which track you wish FDOS recorded on. This is the track that BOOT (Appendix F) will load 
from, depending on the setting of the least significant bit of the switch register. If your computer 
does not have a switch register, track 1 will always load by BOOT. In this case specify track 1 for 
SYSGEN. Enter a carriage return (<cr>). 

8) SYSGEN will copy FDOS onto the disk on the specified track, and then type: 


FDOS PROPERLY WRITTEN, AGAIN? 


9) If you wish to record FDOS on another track or another disk, type Y<cr>. SYSGEN now goes back to 
step 4. If you have finished with SYSGEN, simply enter <cr> and SYSGEN returns to FDOS. You may 


now enter the date and proceed. 
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$ FDOS ROUTINES (AS OF 4-JAN-77) 


D000 FDOS EQU QDOOOH ‘sSTARTING ADDRESS OF THE FDOS BEING USED 

DO2A REDFIL EQU FDOS+2AH sSYSTEM INPUT BUFFER 

po2c WRIFIL EQU FDOS*2CH sSYSTEM QUTPUT BUFFER 

D034 BEGIN EQU FDOS*34H sFDOS RESTART 

D037 cl EQU FDOS*+37H #CONSOLE INPUT 

DO3A RI EQu FDOS+3AH #READER INPUT 

D03D ca EQU FbOS*+3DH sCONSOLE OUTPUT 

D040 PO EQU FooS+40H sPUNCH OUTPUT 

DOA3 Lo EQU FUOS+43H $LIST QUTPUT 

D046 CSTS EQU FDOS+46H sCHECK CONSOLE STATUS 

DO49 RESTRT EQU FDOS#49H thRESTART ADDRESS 

DO4C INIT EQU FDOS#4CH ZERO ALL DISKS 

DOA4F FDREAD EQU FUOS*+4FH *#BYTE IN FROM SYSTEM INPUT FILE 

D052 FDWRT EQU FbDOS+52H sBYTE QUT TO SYSTEM OUTPUT FILE 

D055 BYTIN EQU FDOS+55H sBYTE IN FROM FILE AT CHL) 

0058 BYTOT EQU FDOS+58H sBYTE QUT TO FILE AT (HL) 

DO5B BLKIN EQU FDOS+5BH $280 BYTE BLOCK INTO (HL) 

DOSE BLKOT EQU FDOS+5EH 3280 BYTE BLOCK QUT OF (HL) 

D061 RNDOT EQU FDLOS*61H sQUTPUT A RANDOM BLOCK, NO LINKAGES 
D064 OPNIN EQU FDOS*+04H sSOPEN FILE AT (HL) FOR INPUT 

D067 OPNOT EQU FDOS+67H sQPEN FILE AT (HL) FOR OUTPUT 

DO6A CLSOT EQU FDOS#6AH sCLOSE FILE AT (HL) FROM OUTPUT 

DO6D FILNAM EQU FDOS+6DH sGET A FILE NAME FROM TI STREAM 

DO70 LOKFIL EQU FDOS+70H sLOOK FOR THE FILE NAME AT (HL) 

D073 TXTYP EQU FbOS*73H sTYPE OUT TEXT STARTING AT (HL) ONTO CO 
D026 TI EQU FDOS+76H 4#GET THE NEXT CHARACTER FROM THE TXTIN STRING 
D079 TXTIN EQU FDOS# 79H sINPUT A CORRECTED LINE FROM Cl 

po7c DELETE EQU FDOS+7CH #DELETE A FILE FROM THE DISK 

DO7F RENAME EQU FDQS+7FH SRENAME A FILE IN THE DIRECTORY 

DO82 MEMCHK EQU FDOS+82H $FIND THE UPPER BOUND OF AVAILABLE. RAM 


TITLE % SYSGEN TO GENERATE PERSONALIZED FDOS. (C) 1977 K.B. WELLES’ 


8 THIS ROUTINE IS USED TO PUT THE FDOS STARTING AT CONTENTS OF 

§ STRTAD AND CONTINUING FOR BYTCNT BYTES (NOT TO EXCEED 5000) 

$ ONTO TRACK O OR | (DEPENDING ON THE LSB OF INPUT PORT OFFH). 

§ THE DATA IS PUT ON STARTING AT THE INDEX HOLE (NOT THE SECTOR) 


‘ 
$ DATE 17-MAR- 77 
t) AUTHOR KENNETH B. WELLES 
0000 MINI EQU Oo sUSE THE FULL. SIZED DISK 
0010 BOOTST EQU . 10H sBOOTSTRAP START ADDRESS 
OOFF SWR EQU OFFH sTHIS IS THE SWITCH REGISTER INPUT PORT 
IF NOT MINI 
OOFO INPORT EQU OFOH 
OOFO OTPORT EQU OFOH 
O0cO0O LENGTH EQU OCUOH 
0400 DELAY EQU 0400H 
ENDIF 
IF MINI 
INPORT EQU OE8H 
OTPORT EQU Or&H 
LENGTH EQU OEOOH 
DELAY EQU 1 000H 
ENDIF 
D000 FDOS EQU QOLOOOH $FDOS START ADDRESS 
ae pe ay AINPORT $DATA FROM THE FLOPPY 
Q INPORT+1 STATUS BITS OF THE FLOPPY 
OOF2 SRTSWE EQU INPORT+#2 #READ THE SRT STATUS WORD 
pore SRTRR_ EQU INPORT+3 8 INPUTTING THIS RESETS THE USRT TO LOOK 
Fa FDINWT EQU INPORT+4 $KLUGE TO SYNCHRONIZE TO 32 MICRSECS (OR 64) 
OOFO FOWRIT EQU OTPORT sDATA TO BE WRITTEN TO THE FLOPPY 
OOF I SRTTFS EQU OTPORT#1 PORT Q 
ooF2 gnTnes Eau oIpudres sPORT OF THE DEFAULT CHARACTER 
FDOUT EQU OTPORT+3 SEND SIGNALS TO THE FLO 
oan ere on renee tSYNC TO 32 MICROSECS oie 
ORT+5 sTHIS COMMANDS LOADS THE HEAD FOR 3 SECO) 
OOF6 HDUNLD EQU OTPORT+6 STHIS FORCES AN IMMEDIATE HEAD UNLOAD — 
§ THESE ARE SIGNALS TO FDOUT DIRECT FLOPPY. CONTROLS) 
pac WCSEL EQU | tl=TRACK 0-43, O=IRACK 44-76 
Onae FUREST EQU 2 sUSE TO RESET A FILE UNSAFE CONDITION 
DIRIN EQU 4 SLOGICAL OR FOR IN TRACK 
fone DIROT EQU NOT DIRIN tAND FOR QUT TRACK 
Soe WRTIGAT EQU 10Q $LOGICAL OR TO START A WRITE 
peak STEPP EQU 200 sLOGICAL OR TO START A STEP PULSE 
STEPM EQU NOT STE PP #LOGICAL AND TO STOP THE PULSE 
8 THESE ARE THE DIRECT S 
0001 texzro” ong ; TATUS LINES OF THE FLOPPY (IN FDSTAT) 
0002 UNSAFE EQU 2 
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5 


OOAA 
OOAC 


210402 
CD73D0 
CD79D0 
C076D0 
FE30 

CADFOO 
FE31 

C20000 
COFBOO 


D3F5 
Cpuco} 
CDOCcO! 
CDOCcOI 
F3 


D3F5 
010000 
2A1601 
EB 
2A1801 


0610 
D3F4 


GTRKOs 


TRZLPs 


PAUSI8 


REDOs 


CKSLPs 


GTNODX# 


GTYSDXs 


PREMBL# 


EQU 
EQU 
EQU 
EQUu 


4 
8 
10H 
20H 


ARE VARIOUS PARAMETERS 


EQU 


ORG 
JMP 


MVI 
ouT 


81H STHIS IS THE SYNC BYTE FOR START OF TRACK 
1°) 
Fbos sALL EXITS GET HERE EVENTUALLY 


BOOTST sSTART ADDRESS 


Ay4 OMAX IMUM Q) 

Ae eT F 4 ATEMPTTS TO WRITE 
H,LOADSK §MAKE SURE. 

ae THE RIGHT DISK IS IN 
TXTIN 

TI 

eye #CHECK FOR A PROPER RESPONCE 

RSTRT $sIF ANY ERRORS, QUIT 

A 

FDOUT $SET UP DISK 0 

FDSTAT 


FDRDY sIS IT READY? 
GTRKO =sNOPE, TRY SOME MORE 


TRAKOT 
FDSTAT $sSTEP QUT UNTIL TRACK O 
TRKZRO 
TRZLP = 8NOT YET, QUT ONE MORE 


H,TRKASK SREQUEST TRACK O OR ! 


TI sGET THE FIRST CHARACTER 
PAUSI THIS IS RIGHT 


RSTRT sTHIS IS WRONG 
TRAKIN $%GET TRACK | 


LOADHD LOAD THE HEAD WELL BEFORE WRITING 
TENMIL 
TENMIL 
TENMIL $REALLY ALLOW SETILING 

SAND DISABLE THE INTERRUPTS !! 
LOADHD $LOAD THE HEAD AND THE CONSTANTS 
B,0 
BYTCNI 
STRTAU 


A.C #CALCULATE A SIMPLE 16 BIT CHECKSUM 


PUT THE DOUBLE CHECKSUM ON THE STACK 
BYTCNT $sTHIS IS THE NUMBER OF BYTES TO SEND TO THE DISK 
STRTAD ‘sADDRESS OF FIRST BYTE 


SRTIFS $sFILL CHARACTER#0 
C,WRTIGAT+WCSEL4+FUREST  $BQ0T DISK O 


B,WRTIGAT+WCSEL 
FDSTAT GET NO INDEX HOLE 
INDX 
GTNODK 
FDSTAT ‘$GET YES INDEX HOLE 
INDX 
GTYSDX 
tour SWRITE GATE ON, FILE UNSAFE RESET 
A, 
END RESET PULSE 
aie + PREAMBLE OF 16 0 BYTES 
B,16 
FDOTWT 
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QOAE 03FO OUT —-FOWRIT 
oa co Oe PREMBL 
Gopa seal NVI A,SYNCB $PUT OUT THE SYNC BYTE 
OOB6 D3F4 ar pelt 
0 0 
Copa aD MOV AL SPUT OUT THE START ADDRESS 
OOBB D3F4 QUT —- FDOTHT 
OOBD D3FO OUT —- FDWRIT 
OOBF 7C MOV AGH 
me 60 fee 
Q 
mB MOY A,E.—»:s SPUT OUT THE BYTE COUNT 
00C5 D3F4 OUT FDOTWT 
00C7 D3FO OUT —-FDWRIT 
eae oe 
4 Q 
Goce DaFO OUT FDWRIT 
OOCE D3F4 Ss OSWRLP# OUT —s FDOT. s0PSYS WRITE LOOP, WAIT FOR READY 
00D0 7E MOV AGM 
00D! D3FO OUT  FDWRIT $SEND THE BYTE 
00D3 23 INK H 
ooos 7A mov ReD 
cube BS ORA E sa SEND OF FILE?? 
7 C2CE00 JNZ —OSW 
CODA Et POPs ‘THIS IS A CHECKSUM 
coe BS Our AUENT 
4 0 
QODE DaFO QUT | FDWRIT $PUT OUT THE CHECKSUM 
OOEO 7¢ MOY AH 
OOE! D3F4 OUT —- FOOTWT 
00E3 D3F QUT —- FDWRIT 
OOES 06 MYL By 
00E6 0610 f 
OOES Dora PSTMBL! OUT | FDOTWT $PUT OUT THE POSTAMBLE 
OOEA D3FO OUT —- FUWRIT 
QOEC 05 DCR 
OOED C2E800 JNZ PSTMBL 
OOFO 3E00 MI : 
OOF2 D3F3 OUT —- FLOUT 
OOF¢ D3F3 OUT — FDOUT 
OOF6 D3F3 OUT FDOUT  sTURN OFF THE WRITE GATE 
QOF8 C3/A0! JMP VERIFY ‘AND ASSURE SELF THAT THIS WORKED!! 


$ THESE ROUTINES STEP THE HEAD IN OR OUT ONE TRACK. PER CALL 


OOFB 3E14 TRAKINS MYI A,DIRIN+STEPP 
OOFD C3020) JMP ENDPLS 

0100 3E10 TRAKOT® MVI A,STEPP 

0102 D3F3 ENDPLS* QUT FDOUT 


0104 EGEF ANI STEPM 
0106 D3F3 OUT FDOUT 
0108 010004 LXI B,DELAY sDELAY FOR 10 MS OR 40 MS. 
010B AF XRA A 
010C OB TENMILS DCX B 
O10D B9 CMP c 
O10E c20Cco! JNZ TENMIL 
Olll BB CMP B 
0112 c20C01 JNZ TENMIL 
0115 co RET 
0116 oo0C BYTCNT# DW LENGTH $NUMBER OF BYTES [0 PUT ONTO TRACK O OR | 
0118 OODO STRTAD® DW OD000r sSTARTING ADDRESS 
OIA D3F5 VERIFY’ OUT LOADhL $MAINTAIN HEAD LOADED FOR ALL NEEDED ATTEMPIS 
O1NC 3681 MVI A,SYNCB $LOAD THE SYNC BYIE INTO THE USRT 
OIE DaF2 OUT SRTRSS 
a DI STIMING REQUIRES NO INTERRUPTS 
012} DBFI GTNDX# IN FDSTAL $WAIT FOR INDEX HIGH 
0123 E610 ANI INUX 
0125 CA2I01 Jz GINDK 
8 DBFI GTYDKs IN FDSTAL 4$WAIT FO 
012A E610 ANI Ix. ee ataee oe 
012C C2280) JNZ GLYDX 
012F DBF3 IN SRTRK_  $RESET THE USRT TO LOOK FOR SYNCB 
0131 DBF4 IN FDINWT $WAIT FOR DATA READY : 
0133 DBKO IN FDRED $GET_FIKST BYTE 
0135 Feu! cL SYNCB sMUST BE SYNC BYTE 
FAILED 41F NO 
0134 bare IN FAILED T, TRY AGAIN?! 
IN FORED $GET START A 
013E 6F MoV LyA ee 
013F DBF4 IN FDINWI 
0141 DBFO IN FDRED 
0143 67 MOV HA 
0144 & PUSH =H ‘SAVE THE TRANSFER ADDRESS 
0145 DBF4 IN FUINWE $GET BYTE COUNT 
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0147 DBFO IN FDRED 


0149 5F MOV E,A 
014A DBF4 IN FDINWT 
014C DBFO IN FURED 
O14E 57 MOV yA 
O14F DBF4 = REDLUPs IN FDINWT $WAIT FOR A BYTE 
0151 DBEO IN FDRED 4G 
0153 BE CMP sila hle 
154 23 — INK H 
0155 CA4FOI Jz REDLOP SCONTINUE COMPARING AS LONG AS DATA IS RIGHT 
0158 E5 PUSH =H SSAVE THE FIRST POINTER TO A BAD BYTE 
0159 2A1601 LHLD  BYTCNT sREMEMBER THE WRITTEN BYTE COUNT? 
015C CD9401 CALL COMPAR =$DE=0LD CoUNT 
OI5F C2700! JNZ FAILED 41F NOT EQUAL, THEN FAILED 
0162 2A180) LHLD © SERTAD 4sDESBYTCNT, HL*=STRTAD 
0165 19 DAD =D SHL*LAST GOOD BYTE + | 
0166 OI POP cag VOESLAST READ GOOD BYTE + 1 
0 SLAST WRITTEN - LAST REA 
016A CA80O! Jz PASSED 1G00D , 
016D FA%00) Ju PASSED 4BETTER (COINCIDENCE) 
0170 219A01 - FAILED# LXI=—s HH ATEMPT 
0179 21 Lxt Ms SREMEMBER THE NUMBER OF TRIES? 
0174 C25F00 JNZ —- PAUSI_—_SUP TO 4. TRIES ARE ALLOWED 
01.77 219801 LXI =H, FALTXT tNOTIFY THE USER OF THE FAILURE 
017A CO73D0 CALL IXTYP 4$BY THE TELETYPE 
017D C30000 JMP ss RSTRT = $ELSE, QUIT 
0180 21C401 PASSED! LXI_ =H PASI XT SNOTIFY THE USER OF A CORRECT WRITE 
0183 CD73D0 CALL IXTYP 
0186 CD79D0 CALL = IXTIN 
0189 CD7600 CALL OTL 
018C FE59 cpl y 
018E CA1000 JZ START 
0191 C30000 JMPsRSTRT 
0194 7C COMPAR! MOV == AH = SHL=DE 
0195 92 suB sO 
0196 CO RNZ 
0197 7D MOV AGL 
0198 93 suBiCié 
0199 C9 RET 
O19A 04 ATEMPT? DB 4 
0198 ODVAG644 FALIXT# DB 13,10,7FDOS FAILED To WRITE AFTER 4 ATTEMPTS? , 13, 104128 


O19F 4F532046 
O1A3 41494045 
O1A7 4420544F 
O1AB 20575249 
OIAF 54452041 
01B3 46544552 
O1B7 20342041 
O1BB 5454454D 
OIBF 5054530D 
01C3 8A : 
01C4 OLUAG644 PASTXT® DB 13,10,%FDOS PROPERLY WRITTEN. AGAIN?’,% “+128 
01C8 4F532050 
OCC 524F5045 
01D0 524C5920 
01D4 57524954 
01D8 54454E2E 
OIDC 20414741 

1EO 494E3FAO 
OlEs 4C4F4144 LOADSK® DB “LOAD THE DESIRED DISK, TYPE "Y"%,% 74128 
O1E8 20544845 
OIEC 20444553 
OIFO 49524544 
O14 20444953 
OlKB 4B2C2054 
O1FC 59404520 

3Y 

0204 57484943 TRKASK# DB “WHICH TRACK, O OR 12%,% 74128 
0208 48205452 
U2UC 41434B2C 
0210 2030204F 
0214 522031 3F 


0218 AO 
0000 END 

DOSE 
ATEMP O19A BEGIN D034 BLKIN DOSB BLKOT DOS 
BOOTS 0010 BYTCN 0116 BYTIN D055 BYTOT oop 
cl D037 CKSLP 0077 CLSOT DO6A co oe nd 
COMPA 0194 CSTS D046 DELAY 0400 Lrg a 
DIRIN 0004 DIROT FFFB ENDPL 0102 FA Ae ea 
FALTX 019B FDINW OOF4 FDOS DOOOM FDO 


FDOUT OOF3 FDRDY 0004 FDREA DO4F FDRED OOFO 
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FOWRI OOFO 
GTNDX O12) 
GTYSD 009C 
INIT DO4C 
LOADH OOFS 
MINI 0000 
OTPOR OOFU 
PO DO40 
REDLO O14F 
RI DO3A 
SRTRR OOF3 
START 0010 
SWR  OOFF 
TRAKI OOFB 
TRZLP 003C 
VERIF OIA 


FOWRT DOS52 
GTNOD 0095 
HDUNL OOF6 
INPOR QOFO 
LOADS 01E4 
OPNIN D064 
PASSE 0180 
PREMB OOAC 
REDO 006B 
RNDOT D061 
SKTRS OOF2 
STEPM FFEF 
SYNCB 0081 
TRAKO 0100 
TXTIN DO79 
WCSEL OOOI 


FILNA 
GTRKO 
HEADL 
LENGT 
LOKFI 
OPNOT 
PASTX 
PSTMB 
RENAM 
RSTRT 
SRTSW 
STE PP 
TENMI 
TRKAS 
TXTYP 
WRIFI 


Beginning on page 108 is a complete machine readable representation (PAPERBYTE® bar codes) of the 
object code for Ken Welles’ SYSGEN routine, as assembled in the listing beginning below. This bar code 
representation uses the absolute loader format, in which each bar code frame (one line of bars running from 
top to bottom of the page) contains a two byte address followed by data which is loaded in ascending order 
starting at that address, 

; The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 
listing does not correspond directly to the variable length records of the bar codes, but in general use a 
fixed length of 16 data bytes. 


0000 C3 00 DO 93 
0010 3E 04 32 9A 01 21 E4 01 CD 73 DO CD 79 DO CD 76 TE 
0020 DO FE 59 C2 00 00 AF D3 F3 DB FI E6 04 C2 26 00 FC 
0030 CD FB 00 CD FB 00 CD FB 00 CD FB 00 CD 00 01 DB- C9 
0040 Fl E6 01 C2 3C 00 21 04 02 CD 73 DO CD 79 DO CD _ FO 
0050 76 DO FE 30 CA 5F 00 FE 31 C2 00 00 CD FB 00 D3 29 
0060 FS CD 0C 01 CD 0C 01 CD OC 01 F3 D3 F5 01 00 00 3F 
0070 2A 16 01 EB 2A 18 01 79 86 4F 78 CE 00 47 23 1B 88 
0080 7B B2 C2 77 00 C5 2A 16 01 EB 2A 18 01 3E 00 D3 AB 
0090 Fl OE OB 06 09 DB FI E6 10 CA 95 00 DB FI E6 10 FC 
00A0 C2 9C 00 79 D3 F3 78 D3 F3 AF 06 10 D3 F4 D3 FO 2A 
00BO 05 C2 AC 00 3E 81 D3 F4 D3 FO 7D D3 F4 D3 FO 7C-  3F 
00CO D3 F4 D3 FO 7B D3 F4 D3 FO 7A D3 F4 D3 FO D3 F4 SA 
00DO 7E D3 FO 23 1B 7A B3 C2 CE 00 El 7D D3 F4 D3 FO 24 
OOEO 7C D3 F4 D3 FO AF 06 10 D3 F4 D3 FO 05 C2 E8& 00 04 
OOFO 3E 00 D3 F3 D3 F3 D3 F3 C3 1A 01 3E 14 C3 02 O1 86 
0100 3E 10 D3 F3 E6 EF D3 F3 01 00 04 AF OB B9 C2 0C_ FS 
0110 01 B&8 C2 OC 01 C9 00 OC 00 DO D3 FS 3E 81 D3 F2 719 
0120 F3 DB FI E6 10 CA 21 01 DB FI E6 10 C2 28 01 DB~ 29 
0130 F3 DB F4 DB FO FE 81 C2 70 01 DB F4 DB FO 6F DB_~ 23 
0140 F4 DB FO 67 ES DB F4 DB FO 5F DB F4 DB FO 57 DB_ DO 
0150 F4 DB FO BE 23 CA 4F 01 E5 2A 16 01 CD 94 01 C2 04 
0160 70 01 2A 18 O01 19 DI CD 94 01 CA 80 01 FA 80 01 C6 
0170 21 9A O1 35 C2 SF 00 21 9B 01 CD 73 DO C3 00 00) = A2 
0180 21 C4 01 CD 73 DO CD 79 DO CD 76 DO FE 59 CA 10 50 
0190 00 C3 00 00 7C 92 CO 7D 93 C9 04 OD 0A 46 44 4F SE 
O1A0 53 20 46 41 49 4C 45 44 20 54 4F 20 57 52 49 54 41 
O1BO 45 20 41 46 54 45 52 20 34 20 41 54 54 45 4D 50 16 
01CO 54 53 OD 8A OD OA 46 44 4F 53 20 50 52 4F 50 45 27 
01DO0 52 4C 59 20 57 52 49 54 54 45 4E 2E 20 41 47 41 5B 
01EO 49 4E 3F AO 4C 4F 41 44 20 54 48 45 20 44 45 53 93 
O1FO 49 52 45 44 20 44 49 53 4B 2C 20 54 59 50 45 20 1D 
0200 22 59 22 AO 57 48 49 43 48 20 54 52 41 43 4B 2C (71 
0210 20 30 20 4F 52 20 31 3F AO 41 
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onan 


onoa 
o-oo 
co-unm 
o-Uuw 
o-aa 
o-<+ 
C-—ook 
o-rm 
o-wvw 
o-n- 
o-mwm 
o-an<c 
o--wo 
o-coc-— 
cown 
ccoaan 
ocouUs 
cocoam 
cook 
coonwmg 
conr 
coocn 
covtu 
coma 
conm 
coo-oco 
coco 


108 


APPENDIX F: Using the BOOT Utility Program 


The BOOT program is a compact (less than 200 bytes) program for the loading of FDOS. BOOT nor- 
mally resides in read-only memory, but could be loaded in from cassette or paper tape if desired. The 
BOOT program will load data from the disk in disk drive 0. BOOT examines the least significant bit of port 
255 (OFFH) and will load data from track 0 if this bit is cleared, or track one if this bit is set. On most S- 
100 computers, this means that BOOT will load from track 0 or 1 when the rightmost switch of the switch 
register is lowered or raised, respectively. Computers without a switch register will read a nonexistent port 
as all 1s, and will therefore load FDOS from track 1. 

The data read in by BOOT is written in a special format (described in Appendix |) by the SYSGEN pro- 
gram (Appendix E). The data on the track tells BOOT where to load the data and how many bytes to load. 
After the data is loaded, BOOT performs a check sum calculation on the data. If the check sum indicates a 
correct data load, then BOOT jumps to the location of the first byte loaded by BOOT. If the check sum 
does not agree with the data, then BOOT will reread the data until a proper read is performed or until user 
intervention. 

The source code for BOOT is listed at the end of this appendix. There are several features that the user 
should note about the code shown. The BOOT program, like FDOS, must reside in memory with a cycle 
time of 500 ns or less in order to operate properly. The source code listed assumes that the BOOT routine 
is stored in a slow read-only memory. To overcome the speed problem, the actual data reading code 
(located from GTRKO to INOUT) is copied from the read-only memory into the area of high-speed user 
memory where FDOS will reside before the code is executed. This assures sufficient execution speed to 
read the data from the disk properly. 

The listed code fills the space not used by BOOT in a 256 byte read-only memory with three diagnostic 
routines: INOUT, LDUNLD, and WRTST. 


INOUT is a routine to test the head movement of the disk. When INOUT is executed it will cause the 
disk head to cycle in and out continuously over all 77 tracks of the disk. 

LDUNLD cycles the disk head load/unload circuitry continuously at about one cycle per second. 

WRTST sends a sequence of ascending integers to the disk interface transmit section. 


After BOOT has been run once in read only memory, these diagnostics will reside in, and can be run in, 
the high-speed system memory. 
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LK ee 


TITLE “BOOT, ROM TO LOAD THE K2 FDOS (C) 1977, K.B. WELLES? 


‘ DATE 15-MAR-77 
‘ AUTHOR K.B. WELLES 


THIS ROUTINE IS MADE TO SIT IN AN ARBITRARILY SLOW ROM 

THE ROM ADDRESS IS BOOTST ; 

GOING TO BOOTST WILL CAUSE THE BULK QF [HIS PROGRAM LO 

BE TRANSFERRED UP TO A FAST (<500 NS CYCLE TIME) 4K BYTE 

RAM AREA. THE RAM AREA STARTS AT LABEL “FDOS*. 

THE CPU THEN TRANSFERS TO AND BEGINS EXECUTING THE 
RELOCATED PROGRAM, WHICH WILL MOVE DISK DRIVE O TO ; 

TRACK O OR | (DEPENUVING ON THE LEAST SIGNIFICANT BIT 

OF INPUT PORT OFFH, TYPICALLY THE SWITCH REGISTER OF ALTAIR, 
IMSAI MACHINES), AND READ IN THE OPERATING SYSTEM WHICH RESIDES 
QN THAT TRACK AND BEGINS AT THE INDEX PULSE. 


cFoo BOOTST EQU  OCFOOH sBOOTSTRAP START ADDRESS 
00 FF SHR EQU=sOFFH_~—sSTHIS IS [HE SWITCH REGISTER INPUT PORT 
D000 FDOS EQU © ODOOOH fTHIS IS IHE START OF THE 4K RAM TO USE FOR THE 0S 
1.000 OFFSET EQU — FUOS*UFOUH-BOUTST $PUTS THE BOOT IN THE LAST .25 K RAM 
0400 DELAY QU  —400H 
OOFO INPORT EQU  — OFOH 
OOFO OTPORT EQU  — OFOH 
Foo ORG —- BOOTST : 
CFOO 2113CF BOUT! LXI  — H,MOVCOD ‘START ADDRESS OF CODE To BE MOVED 
CFO3 1113DF XI D, MOVCOD+OFFSET koehiee 
CFO6 06E5 MVI By ENDCOD-MOVCOD $NUMBER OF BYTES To BE MOVED 
CFO8 7E MVLOP? MOV A,M ‘GET A BYTE TO BE MOVED 
CFO9 12 SIAX D sMOVE IT 
CFOA 23 INK oH 
CFOB 13 INK D sUP THE POINTERS 
CFOC 05 DCR soi $DOWN THE COUNTER 
CFOD C208CF JNZ  -MVLOP 
CFIO C313DF JMP = MOVCOD*0FFSET © sTHEN JUMP TO THE FIRST BYTE 
MovCoD # 
ooFo FDRED EQU __ INPORT SDATA FROM THE FLOPPY 
OOF! FDSTAT EQU INPORT#1 SSTATUS BITS OF THE FLOPPY 
OoF2 SRTSWE EQU  INPORT#2 $READ THE SRT STATUS WORD 
OOF3 SRTRR  EQU =‘ INPORT#3 $ INPUTTING THIS RESETS THE USRT TO LOOK 
OOF4 FDINNT EQU —_INPORT+4 $KLUGE TO SYNCHRONIZE TO 32 MICRSECS 
OOFO FDWRIT EQU  —OTPORT SDATA TO BE WRITTEN TO THE FLOPPY 
OOF | SRTIFS EQU  «OTPORT+1 $PORT OF THE DEFAULT CHARACTER 
OOF2 SRTRSS EQU  OTPORT#2 
OOF 3 FDOUT EQU —OTPORT#3 $SEND SIGNALS TO THE FLOPPY 
OOF4 FDOTHT EQU  — OTPOKT#4 $SYNC TO 32 MICROSECS 
OOFS LOADHD EQU OF PORT#5 STHIS COMMANDS LOADS THE HEAD FOR 3 SECONDS 
OOF6 HDUNLD EQU — OTPORT#6. STHIS FORCES AN IMMEDIATE HEAD UNLOAD 
$ THESE ARE SIGNALS TO FDOUT (DIRECT FLOPPY CONTROLS) 
0001 WCSEL EQU 1 $l=TRACK 0-43, OmTRACK 44-76 
0002 FUREST EQU 2 SUSE TO RESET A FILE UNSAFE CONDITION 
0004 DIRIN EQU 4 LOGICAL OR FOR IN TRACK 
FFFB DIROT EQU  —_—NOT DIRIN SAND FOR OUT TRACK 
0008 WRIGAT EQU 100 SLOGICAL OR TO START A WRITE 
0010 STEPP EQU 200 sLOGICAL OR TO START.A STEP PULSE 
FFEF STEPM QU NOT STEPP sLOGICAL AND TO STOP THE PULSE 
$ THESE ARE THE DIRECT STATUS LINES OF THE FLOP 
0001 TRKZRO EQU 1 ai 
0002 UNSAFE EQU 2 
0004 FORDY EQU 4 
0008 SCTR EU 68 
0010 INDK —-EQU 10H 
0020 HEADLD EQU 20H 
$ THESE ARE VARIOUS PARAMETERS 
0081 SYNCB EQU = 81H ~— 4THIS IS THE SYNC BYTE FOR START OF TRACK 
CFI3 31F7DF GTRKO# LXI SP, STACK+0FFS 
CFI6 AF KXRA A “ 
CFI D3F3 QUT FOOUT4SET UP DISK 0 
0 LOAD 
cFI9 DFS ou LOADHD 4KEEP THE HEAD LOADED FOR 3 SECONDS 
CFID £604 ANI FDROY 41S IT READY? 
CFIF C2130F JNZ  GTRKOWOFFSET — §NOPE, TRY SOME MORE 
CF22 CDACDF CALL TRAKIN#*OFFSET 
CF25 CDACDF CALL  TRAKIN#OFFSET 
CF28 CDACDF CALL TRAKIN¢0FFSET 
CF2B CDACDE CALL — TRAKIN#OEFSET 
CF2E CDBIDF TRZLP® CALL  TRAKOI#OEFSET 
CF3! DBFI IN FOSTAT $STEP QUT UNTIL TRACK 0 
CF33 E601 ANI TRKZRO 
CF35 C22EDF JNZ - TRZLP#OFFSET SNOT YET, OUT ONE MORE 
OB FF IN SWR — $WE ARE AT 0, DO'WE WANT 17 
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TRYGN3 


GTNODXs 


GTYSDXs 


REDLOPs 


CKLPs 


ERROR’ 
TRAKIN# 
TRAKOT# 
ENDPLS# 
DLAYs 
TENMIL# 


\ SIF THIS SWITCH IS 1, TH 
TRAKIN¢OFFSET pT ae EE) 


LOADHD $MAINTAIN HEAD LOADED FOR ALL NEEDED ATTE ) 
pri ietg $LOAD THE SYNC BYTE INTO THE USRT rane 


tTIMING REQUIRES NO INTERRUPTS 
aed sWAIT FOR INDEX HIGH 


GTNODX+#0 FFSET 

FDSTAT $WAIT FOR INDEX LOW 
INDX 

GTYSDX¢#0FFSET 


SRTRR_  $RESET THE. USRT TO LOOK FOR SYNCB 
FDINWT $sWAIT FOR DATA READY 

FDRED %GET FIRST BYTE 

SYNCB $MUST BE SYNC BYTE 

TRYGN#) FFSET tIF NOT, TRY AGAIN!! 
FDIN®T 

FDRED %GET START ADDRESS 


H #SAVE THE TRANSFER ADDRESS 
FDINWI $GET BYTE COUNT 


D sSAVE THE BYTE COUNT 


FDINWT ‘sWAIT FOR A BYTE 

FDRED #GET THE BYTE 

MA sSTORE THE BYTE 

H 

Db 

A,D 

E sPOINTER, COUNTER ADJUSTED 
REDLOP*OFFSED $NEXT BYTE IF NOT DONE YET 


FDUINWL 

FDRED 

L.A sHL GETS THE CHECKSUM 
FDINWE 

FDRED 

H,A 

D sDE IS THE BYTE COUNT 

B sBC IS THe ADDRESS 

B sRESAVE THE ADDRESS 

H sSAVE THE READ CHECKSUM 
H,0 sCALCULATE THE CHECKSUM 
B sGET A BYTE 

L 

L,A 

A,H 

oO 

HA tHL*HLt+A 

B 

D 

A,D SoS ee 
E sIs THE COUNTER ZERO YET? 
CKLP+0FFSET 

D tTHIS WAS THE READ CHECKSUM 
A,D 

H 

ERROR+0 FFSET s00PS, MISREAD 
ig 


¢ IF HUNKY=DOORY, THEN GOTO TRANSFER ADDRESS 
GTRKO+0 FFSET tELSE, TRY AGAIN FOREVER. 


A,DIRIN+STE PP 

ENDPLS+0 FFSET 

A,STEPP 

FDOUT 

STEPM 

FDOUT 

B,DELAY sDELAY FOR 10 MS. 
A 


B 
Cc 
TENMIL*OFFSET 
B 
TENMIL*OFFSET 


ae ee we Se ee 
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§ THE FOLLOWING ROUTINE MOVES THE DISK IN 76 TRACKS, THEN QUT 76 TRACKS 


¢ THIS CONTINUES FOREVER. JUMP TO THIS POINT TO TEST YOUR INTERFACE 


INOUTs MVI 
INLP® CALL 


OTLPs CALL 


§ THIS ROUTINE LOADS AND UNLOADS THE HEAD CONTINUOUSLY 
¢ JUMP TO THIS POINT (#OFFSET) To TEST THE INTERFACE 


LDUNLD# QUT 


D,76 
TRAKIN¢OFFSET 


D 
INLP 


D,76 
TRAKOT+OFFSET 


D 
OTLP 
INOUT 


LOADHD 
TENMIL 
HDUNLD 
TENMIL 
LDUNLD 


s THIS ROUTINE SENDS SEQUENTIAL VALUE BYTES TO THE DEFAULT WRITE SECTION 
¢ OF THE USRI EVERY TEN MILLISECONDS. JUMP TO THIS POINT TO TEST THE INTERFACE 


WRTST# CALL 


DS 
STACK® DB 


ENDCODs 
END 


BOOTS CFOO 
DIROT FFFB 
ERROR CFA9 
FDOUT 00F3 
FDARI OOFO 
GTYSD CF4D 
INLP CFC9 
LQADH OOF5 
OTLP CFD2 
SRTRR OOF3 
STACK CFF7 
SYNCB 008! 
TRKZR 0001 
WCSEL 0001 


DLAY#0FFSET 


A.D 
SRTTFS 


D 
WRTST#) FFSET 


4 
(0) 


#RESERVE 2 LEVELS OF STACK 


SEND OF CODE TO BE RELOCATED 


MYLOP 
REDLO 
SRTSW 
STEPP 
TRAKI 
TRZLP 
WRTST 


eae a 


Beginning on page 114 is a complete machine readable representation (PAPERBYTE® bar codes) of the 
object code for Ken Welles’ BOOT routine, as assembled in the listing beginning below. This bar code 
representation uses the absolute loader format, in which each bar code frame (one line of bars running from 
top to bottom of the page) contains a two byte address followed by data which is loaded in ascending 
order starting at that address. 

The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 
listing does not correspond directly to the variable length records of the bar codes, but in general use a 
fixed length of 16 data bytes. 


CFOO 21 13 CF 11 13 DF 06 ES 7E 12 23 13 05 C2 08 CF 55 
CF10 C3 13 DF 31 F7 DF AF D3 F3 D3 FS DB Fl E6 04 C2 71 
CF20 13 DF CD AC DF CD AC DF CD AC DF CD AC DF CD B1 DO 
CF30 DF DB F1 E6 01 C2 2E DF DB FF E6 01 C4 AC DF D3 44 
CF40 F5 3E 81 D3 F2 F3 DB Fl E6 10 CA 46 DF DB Fl E6- CF 
CF50 10 C2 4D DF DB F3 DB F4 DB FO FE 81 C2 3F DF DB~ AO 
CF60 F4 DB FO 6F DB F4 DB FO 67 ES DB F4 DB FO SF DB_ E8 
CF70 F4 DB FO 57 DS DB F4 DB FO 77 23 1B 7A B3 C2 75 9E 
CF80 DF DB F4 DB FO 6F DB F4 DB FO 67 D1 Cl C5 E5 21 46 
CF90 00 00 OA 85 6F 7C CE 00 67 03 1B 7A B3 C2 92 DF 2D 
CFAO DI 7A 94 C2 A9 DF 7B 95 C8 C3 13 DF 3E 14 C3 B3 TE 
CFBO DF 3E 10 D3 F3 E6 EF D3 F3 01 00 04 AF 0B B9 C2~ C8 
CFCO BD DF B8 C2 BD DF C9 16 4C CD AC DF 15 C2 C9 CF A4 
CFDO 16 4C CD BI DF 15 C2 D2 CF C3 C7 CF D3 F5 CD BD E2 
CFEO CF D3 F6 CD BD CF C3 DC CF CD B9 DF 7A D3 Fl 14 16 
CFFO C3 E9 DF 00 00 00 00 00 00 00 00 00 00 00 00 00 8B 
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Oban 
OlLws+ 
OLA 
Onmaw 
Oncaea 
Uk. aoo 
OUlow 
Ounr— 
UOlLwnk 
ObtO 
OLman 
Onan 
Obn—wz 
ULnco 


on-mn 
o-oo 
om 
o-w 
onr-mn 
o-wt 
on-m 
orn 
o-o-— 
o-oo 
con 
ooo 
oon 
oovw 
oom 
cow 
com 
con 
coc 
ccc 
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APPENDIX G: 


Patching Your Own I/O Devices to FDOS 


In addition to the floppy disk drive, FDOS supports five additional input and output peripheral devices 
for data transmission and reception. These peripheral devices are: 


Console Input (keyboard) 

Console Output (video display, teletypewriter, etc.) 

Reader Input (paper tape reader, audio cassette) 

Punch Output (paper tape punch, audio cassette) 

List Output (teletypewriter, line printer, or other hard copy unit) 


All five of these devices are treated by FDOS as devices that send or receive exactly one byte or ASCII 
character each time that they are referenced. This is always true of keyboards, teletypewriters, and video 
displays, and almost always true of paper tape readers, punches, and most line printers. For cassette inter- 
faces and some other available devices, this is not true. Methods of programming around this problem will 
be discussed in this appendix. 

FDOS does not require that you have all of these devices. For FDOS to run properly, the user is re- 
quired only to have a console input device and a console output device. These may be a single device, 
such as a teletypewriter or a video terminal, or two separate devices such as a keyboard and a TV type- 
writer, or some functional equivalent. FDOS requires that three I/O device routines be present to perform 
all console input and output. These are the User Accessible Routines Cl, CO, and CSTS. The operation 
of these routines was described in Pass 3, but will be explained briefly here. 

In order to permanently interface your console device to FDOS, you must first load FDOS, then add 
the Cl, CO, and CSTS routines described below, and finally perform a SYSGEN (Appendix E) to record 
the properly patched version of FDOS back onto the disk. Appendix H describes the step by step pro- 
cess of system initialization. 


Cl: The user should enter their own Cl routine within FDOS in the memory locations from D003H 
to DOOFH, inclusive. The Cl routine must perform the following actions: the routine waits until 
a character is available from the console; the 7 bit ASCII value is stored in the A register with the 
most significant bit of A cleared; the routine must end with a return (RET) instruction; Cl cannot 
modify any registers except A and the flags. 


A sample Cl routine for an IMSAI SIO-2 board is shown in example G.1. 


CO: Users should enter their own CO routine within FDOS in the memory locations DO10H to 
DO1DH, inclusive. The CO routine must perform the following actions: the routine waits until 
the console is ready to accept a new character; the 7 bit ASCII value in C is sent to the console; 
the routine must end with a return (RET) instruction; CO cannot modify any registers except A 


or or the flags. 


Note that the most significant bit of the C register may be either set or cleared. It is the user's respon- 
sibility to mask off this bit before sending the ASCII value to the console if the user’s console is sensitive 
to this bit. This bit is set whenever the character being sent to the console is the echo of a RUBOUT (or 
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DELETE) key typed during execution of the TXTIN routine. If the user’s console does not support a 
backspace or cursor control, then this bit is masked off and ignored. This causes the RUBOUT echo char- 
acter (the character deleted from the TXTIN buffer by this RUBOUT) to be printed. If the user’s console 
does support backspace, then the user can include a routine which, upon sensing the most significant bit 
set, generates a backspace instead of a printed character. This allows RUBOUTs to occur and appear in 
real time on the user’s console device. 

A sample CO routine for an IMSAI SIO-2 board is shown in example G.2. 


CSTS: User’s should enter their own CSTS routine within FDOS in the memory locations from 
DO1EH to D027H, inclusive. The CSTS routine must perform the following actions: the routine 
checks to see if a key has been struck on the user’s console since the last call to the Cl routine. 
If so, a character is available to be read. CSTS does not read the character, but stores the value 
OFFH in the A register and returns. If no character is available (no key has been typed since the 
last call to Cl) then the value 0 is stored in the A register. The routine must end with a return 
(RET) instruction. CSTS cannot modify any registers except A or the flags. The flags need not be 
set to indicate the contents of the A register upon return. 


A sample CSTS routine for an Imsai S1O-2 board is shown in example G.3. 


The spaces provided within FDOS for the Cl, CO, and CSTS routines are small, but are adequate for 
any console device and interface which require the type of access shown in examples G.1, G.2, and G.3. 
However, some interfaces and console devices (especially those of homebrew origin)require more elaborate 
software to transmit or receive data. This software cannot fit in the few bytes allotted within FDOS, and 
frequently this software also requires the use of several registers. In this instance, the user should write 
the Cl, CO, and CSTS routines that do not fit, with the appropriate register saves (PUSHes and POPs) 
which perform the required input, output, or status sensing. These routines should be assembled in some 
area of user memory or read-only memory outside of the FDOS area (ODOOOH to OdFFF8H). The user 
should then insert jumps to the addresses of the external, Cl, CO, and/or CSTS routines in locations DO03H, 
DO10H, and DO1EH, respectively. 

All FDOS programs access the console through Cl, CO, and CSTS routines as listed in Appendix A. 
This means that as soon as you change your own version of FDOS to fit your own console device, all 
software written for FDOS will immediately work on your computer. Similarly, if all of the software 
that you write accesses the console only through the Cl, CO, and CSTS User Accessible Routines, then 
your software will run on any other person’s version of FDOS with no special patches required. This 
feature allows you to write easily transportable software, a feature that is very important to make soft- 
ware easy to use, share, or market. 

The other three devices supported by FDOS (Reader, Punch, and List device) are accessed by the RI, 
PO, and LO routines. FDOS does not provide space within the operating system for these routines, but 
it does provide a jump table to call the RI, PO, and LO routines when they are stored in user memory 
or read-only memory separate from FDOS. To insert these routines into FDOS you need only insert the 
address of the RI, PO, and LO routines in the jump table and then SYSGEN the customized FDOS. 


LO: The user should write a LO routine external to FDOS and put the address of this LO routine 
into locations D044H and D045H (low byte first). The LO routine must perform the following 
actions: the routine must wait until the list device is ready to accept a new character; the 7 bit 
ASCII value in C is then sent to the list device; the LO routine must end with a return (RET) 
instruction; LO cannot modify any registers except A or the flags. 


PO: The user should write a PO routine external to FDOS and put the address of this PO routine 
into locations D041H and D042H (low byte first). The routine must perform the following ac- 
tions: the routine must wait until the punch device is ready to accept a new character; the byte 
to be punched is sent from register C to the punch device; the PO routine must end with a return 
(RET) instruction; PO cannot modify any registers except A and the flags. 

If the user has an audio cassette as an output device, more extensive software is required to 
perform the PO routine. To implement PO correctly the user must be able to start and stop the 
cassette drive under software control. The PO routine should store the bytes sent to it one-by-one 
in a buffer until some large number of data bytes has accumulated. The PO routine should then 
turn on the cassette recorder, wait until the motor gets up to speed, send the entire data buffer, 
then turn off the recorder. This process is known as “data blocking,” and the programmer is 
referred to the BYTOT routine discussed in Pass 6 as an example of this process. 
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RI: The user should write an RI routine external to FDOS and put its address into locations D03BH 
and DO3CH (low byte first). The routine must perform the following actions: the routine must 
wait until a byte is available from the read device; the byte is read in from the reader and stored 
in the A register; the reader is triggered to read in the next byte, and the routine must end with 
the byte just read in the A register, the carry bit cleared, and must not modify any registers 
except A or the flags. If the read device senses that the end of the file has been reached (e.g. 
out of paper tape), the carry bit is set and no value is put in the A register. This end of file in- 
dicator is important to tell FDOS when the end of the input data has been reached. The routine 
must end with a return (RET) instruction. 

If the user has an audio cassette as the input device, more extensive software is required to per- 
form the RI routine. To implement RI correctly the user must write a complement to the cassette 
data blocking routine described in the PO section above. This routine is quite logically called a 
data unblocking routine. When RI is first called, it must turn the cassette on, read a block of 
data into a buffer, turn the cassette off and then return the first byte read in the A register. 
Successive calls to RI will take successive bytes from the buffer until all of the data read in has 
been used. At this time, RI reads in another block of data and starts at the beginning of the 
buffer again. The programmer is referred to the BYTIN routine of FDOS discussed in Pass 5 
as an example of how data unblocking functions. 


After the user makes any of the above changes to FDOS, the SYSGEN routine is used to store the 
customized version of FDOS onto a disk. This disk will then contain a version of FDOS patched to the 
user’s own personal I/O devices. 


eT 
_ SSS 


ORG 0D003H 
CIU: IN 3 ;IMSAI SIO-2 board addressed at 2,3 
ANI 2 
JZ cIU ;wait until a character is typed 
IN 2 ;get the character 
ANI 7FH ;wipe off any parity 
RET ;return to the calling program 


Example G.1: A sample Cl routine for an Imsai SIO-2 


board. 
ORG 0D010H 
COU: IN 3 sIMSAI SIO-2 board addressed at 2,3 
ANI 1 
JZ COU swait until the first character 
MOV A,C ;has been sent 
ANI 7FH ;clear the msb 
OUT 2 ssend the ASCII value 
RET ;return to the calling program 


Example G.2: A sample CO routine for an Imsai SIO-2 


board. 
DO1EH 
CSTSU: ie 3 sIMSAI SIO-2 board addressed at 2,3 
ANI 2 scheck if a character is ready 
MVI AO sthis causes no flag changes 
RZ sif no character, return with A=0 
CMA selse turn A into OFFH 
RET jand return 


Example G.3: A sample CSTS routine for an Imsai SIO-2 
board. 


APPENDIX H: System Initialization 


This appendix is written for the person who has a computer system and a floppy disk interface like 
that in Appendix K. This appendix describes how to initialize FDOS to your system from this book in 
a step by step manner. 


1) Required hardware: The user must have an 8080, Z80, or 8085 computer system. This computer must 
have 4096 bytes of programmable memory from address DOOOH to DFFFH. The cycle time of the 
microprocessor and this memory must be less than or equal to 500 ns with no wait states. The computer 
must have at least 1024 bytes of programmable memory starting at memory location 0, with the same 
speed requirements. The user must have a floppy disk drive and a floppy disk interface which is func- 
tionally equivalent to the interface described in Appendix K. 

2) Load FDOS: The user should load the FDOS code into the memory starting at address DOOOH. FDOS 
may be loaded from the PAPERBYTE® bar code representation of the FDOS object code beginning 
on page 149, or from paper tape available from the author (see Appendix O). FDOS can also be loaded 
with a BOOT loader from a disk containing a copy of FDOS. Refer to Appendix F for instructions 
on using BOOT. 

3) Customize FDOS: Referring to Appendix G, the user should enter the console 1/O routines (CI, CO, 
CSTS) required for the user’s particular console device and interface. 

4) Load SYSGEN: SYSGEN can be loaded from the PAPERBYTE® bar code representation given in 
Appendix E, from the object code listing of SYSGEN given in Appendix E, from paper tape available 
from the author, or from a disk containing SYSGEN. When loading SYSGEN from a disk, refer to 
Appendix E for instructions on how to load SYSGEN without destroying the FDOS DATE function. 

5) Run SYSGEN: SYSGEN starts at address 10H. Appendix E describes the options for using SYSGEN. 
Note the proper operation of SYSGEN; typing to and from the console device assures the user that 
the Cl and CO routines are entered correctly. 


At the completion of the SYSGEN program, FDOS has been successfully initialized on the user’s com- 
puter. Refer to Pass 1 for instructions on how to use FDOS. 
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TITLE 


¢ LAST MODIFIED 
§ FDOS RQUTINES 


MINI 


PRTDEL 


EQU 


EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQu 


ARE THE 


EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 


“K2 FDOS COPYRIGHT FEBRUARY 19.77 VERSION |. 


9-MAY-78 
FOR STORAGE ON TRACK O OR 1 


t+) #CONDITIONAL ASSEMBLY DIRECTIVE, FULL SIZE DISK 


ODOOOH #WHERE FDOS RAM STARTS 
RAMST+#+4095 sWHERE FDOS RAM ENDS 
RAMND-7 8THE FDOS STACK POINTER STARTS HERE 


64 LENGTH OF THE TXTIN BUFFER 
ERROR CODES 


#DISK READ ERROR 

#DISK WRITE ERROR 

tA DUPLICATE FILE EXISTS 
tNO SUCH FILE EXISTS 
sTHE DIRECTORY IS FULL 
sTHE ENTIRE DISK IS FULL 


8NQ SUCH DISK EXISTS . 
s IMPROPERLY NAMED FILE 

10H $NO .SUCH FDOS COMMAND 

WH STHIS FILE CANNOT BE RUN 

12H tA PARTIAL FILE HAS BEEN DELETED 


CDNAVAWN— 


§ THE FOLLOWING VARIABLES ARE ASSEMBLED To DIFFERENT VALUES DEPENDING 
¢ ON WHETHER YOUR SYSTEM USES A FULL SIZED FLOPPY OR A MINIATURE FLOPPY 


BLOCKS 
TRACKS 
DSKLIM 
HLDLY 


\elocks 
TRACKS 
DSKLIM 


IF 

EQU 
EQU 
EQU 


ENDIF 


$ THE FOLLOWING 
¢ STANDARD 


KBSTAT 
KBRDY 

PNTRDY 
KBDATA 


Clus 


Cous 


CSTSUs 


MINI sFOR A MINIATURE FLOPPY 
8 $8 BLOCKS/TRACK 


35 $35 TRACKS/DISK 

2 $2 DISKS/SYSTEM 

33 #1 SECOND HEAD LOAD DELAY 

NOT MINI $FOR A FULL SIZED FLOPPY 


25% 116 BLOCKS/TRACK2 260 xy - so4y MES) FACES 


$8 DISKS/SYSTEM 
$10 MS DELAY 


Ww 
27% 477 TRACKS/DISK 
3 


PORT ASSIGNMENTS ARE TYPICAL, BUT ARE NOT ALTAIR OR IMSAI 


RAMST $THIS IS THE ORIGIN FOR ALL FUOS 
JBEG sTHE OFFSET TO THE START 
RAMST+3 


KBSTAT $sGET THE KEYBOARD STATUS 
KBRDY $#1S A CHARACTER WAITING? 
CcIU 4NOPE, WAIT FOR IT 
KBDATA sYEP, GET IT 

7FH SWIPE OFF EXTRANEOUS BITS 


RAMST+1 0H 


KBSTAT 
PNTRDY 
co 

Ac 
7FH 
KBDATA 


RAMST+1 EH 

KBSTAT ¢IS THE KEYBOARD READY? 

KBRDY 

A,FALSE sSET UP A WITH NOT READY 
SRETURN HERE IF NOT READY 
sCONVERT A TO TRUE 
sCHARACTER IS READY!! 

RAMST+28H 


sREAD BEYOND END OF FILE, OR AN UCLOSED FILE IS READ 


3) F8DF 
CO22D9 
CD41 DA 
C3C6D0 


OE2D 


Vee 
SPHOLDs DW 0 
OW ; 


JENDS = JMP \~ 


ORG 
JMP 


RST 
DB 
MOV 
RST 
DB 


CALL 
Db 


MODCAL® XTHL 
7 Wov 


MODLOD® XRI 


xX 
Cpl 


MODLI# INX 


BEGIN§ —— 
RESTRT® LXI 


SINCAL2 CALL 
CALL 
JMP 


NXTINS# MYI 


FDOSP $sSYSTEM INTERNAL STACK POINTER 

REDFIL #SYSTEM INPUT BUFFER 

WRTFIL $SYSTEM OUTPUT BUFFER 

DAYOM $2 BYTES DAY {BCD), MONTH/YR 

TXTPNT $2 BYTE POINTER FOLLOWED BY BUFFER 

LSTERR sADDRESS OF STORED BYTE OF LAST ERROR OCCURRENCE 


BEGIN ‘$BEGIN FDOS FROM SCRATCH 


C1U tTHIS IS THE USERS CONSOLE IN ROUTINE ADDRESS 
CIU STHIS IS THE DEFAULT FoR RI 

Cou sTHIS IS THE USERS CONSOLE OUT ADDRESS 

COU sTHIS IS THE DEFAULT FOR PO 


cau sTHIS IS THE DEFAULT FOR LO 

CSTSU  $sUSERS CONSOLE STATUS ROUTINE ADDRESS 
RESTRT ‘#RE-ENTER FDOS FROM A CHAINING PROGRAM 

INIT sMOVE ALL OF THE DISK DRIVES TO TRACK Of! 
FDREAD $READ A BYTE FROM THE OPEN SYSTEM INPUT FILE 
FDWRT $sWRITE A BYTE TO THE OPEN SYSTEM OUTPUT FILE 
BYTIN. ¢sBYTE IN FROM FILE AT (HL) 

BYTOT sBYTE OUT TO FILE AT CHL) 

BLKIN $256 BYTE BLOCK IN TO (HL) 

BLKOT $256 BYTE BLOCK QUT TO (HL) 

RNDOT sCONTIGUOUS BLOCK OUTPUT (NO LINKAGES) 
OPNIN  $OPEN FILE (HL) 

OPNOT = $OPEN FILE (HL) FOR OUTPUT 

CLSOT = =sCLOSE FILE (HL) OUFPUT 

FILNAM $GET A FILENAME FROM TI 

LOKFIL sDETERMINE THE PRESENCE OF A FILE 


TXTYP 4sTYPE THE TEXT THAT STARTS AT (HL) gv 

TI $GET THE NEXT BUFFERED CHARACTER pd 

TXTIN  $sBUFFER A LINE o OOW 
DELETE #DELETE A FILE FROM THE DISK Wt sR UN 
RENAME. $RENAME A FILE ON THE DISK A tee 
MEMCHK $RETURN THE END OF MEMORY-40H IN A,B ye HTT, 


RNDIN. $READ A BLOCK WITH NO LINKAGES 


é t 
MODCAL $FDOS POSITION INDEPENDENT CALL, DESTROYS A \Y wu 


2 
THIS ROUTINE ALLOWS ALL FDOS FUNCTION CALLS THROUGH ONE ADDRE 
BY A SINGLE NUMBER, IN THE FOLLOWING MANNER(S) 


8H 
MODCAL 8 (MODCAL*FD0S+86H) 
tTHIS CALLS THE CI ROUTINE 


sTHEN THE CO ROUTINE 


Q0008H sTHIS ALSO WORKS, IN CASE YOU DON’T WANT TO 
9 sUSE THE RST 


aM IS THE ROUTINE NUMBER, M#l IS NEXT INSIR 
A,M tAsROUTINE NUMBER 
H 3M IS NEXT INSTR 

tA RET INSTR WILL NOW OPERATE PROPERLY 
(JEND-JBEG)/3 sCOMPARE TO THE NUMBER OF VALID ROUTS 
MODLOD $NOT ROUTINE CALL, HOW ABOUT LHLD CALL? 


H sONLY A,PSW 1S CHANGED, REST IS SAVED 
L,A 4$L=ROUT # 
A sA=2eROUT 
L $ A=3*ROUT 


JBEG AND OFFH $LOW PART OF TABLE 


L,A 
~-H,JBEG/256 $HL POINTS TO THE PARTICULAR JUMP 
. $RESTORE H, A RET INSTR. JUMPS TO THE ROUT 
#80, GO DO IT 


80H sCLEAR MSB 

5 sONLY O=4 VALID 

H, SPHOLD=2 

H 

H sUP THE POINTER BY 2 


A §DOES IT PPOINT TO THE DESIRED ADDRESS YET? 
MODLI sNOPE, DO IT AGAIN 
A,M sAsLOW ADDRESS BYTE 


H,M tH=HIGH ADRESS BYTE 
L,A tHL*ADDRESS 
tAND RETURN 
SP, FDOSP $LOAD THE STACK POINTER 
I sMOVE ALL DISKS TO TRACK ZERO 
STNON $PUT OUT THE SINON MESSAGE, GET THE DATE. 
NXTLET sTHIS ALLOWS CHAINING AND INITIALIZING 


Ci," 
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poco ©03DD0 CALL co 8PROMPT A RESPONCE 


CALL TXTIN ‘GET A LINE 
bocs Cotes ONXTLET! GALL TI SGET A CHARACTER 
DOCS CAC6DO Jz NXTLET 9SKIP ALL INITIAL SPACES 
Docc 21BEDO LXI H,NX 
H 
bobo Fe Cw SRETURN IF END OF LINE AND NO COMMAND FOUND 
FE ~~ CPI “RY gR? — RUD 
Dob3 CA TaD! Jz RR ices’ 
DODS FES3 Cpl ose 8S? — save 
DOD8 CAF8DO Jz WW ih 
DODB FE4A cr oer 132 — DP 
DD CAES5DO 
bok cpCeD3 ERO! CALL EERTYP SUNRECOGNIZED COMMAND 
DOES & RET SAND GET ANOTHER INSTRUCTION 
OE5 cD3CD3. Jus «= CALL” LOOK FOR A SPACE 
BOE FAZODO JM ERIO —- §NO_ NUMBER FOUND 
DOEB C2E5D0 =JSNZ JJ 
DOF oe ant Pusha ier UP A RET JUMP TO THE DESIRED LOCATION 
DOF2 2AEAD9 
DCX H 
Dore 7e MOV AyM $A= TERMINAL CHAR ON A LONG COMMAND STRING 
DOF? C9 _—RET 
DOF8 2130DE Wwe LXI H,WRTFIL ‘THE WRITE BUFFER IS USED 
DOFB CDD7D1 ALL CHKNA, Cyaan $GET A FILE NAME 
DOFE FAS7DI OM WN4 fNO' FILE NAME WAS FOUND 
DIO! D257DI INC nna FILMA, LoKeie~Difore 
DIO4 CDA8D5 __CALL = QPNOT.~—s- S0PEN IT FOR OUTPUT. 
LOKEIL-QYLOPN , ONE —W XTSL-T 
DIO7 COEAD! whit CALL_—s AST SASTERISK PROMPT "*?!” 
DIOA FE4C PI sit yg tt 1S THE LIMITS 
DIOC CA20D1 ) 
DIOF FES! CPI “ae $0 IS QUIT THE FILE 
DIN! CAGEDI Jz, NoGo #0 CLOSES THE FILE, NO TRANSFER 
DII4 FE4 cp 3 
D116 CASCDI JZ CLOSIT 7 
DII9 CDC9D3 CALL ERTYP_ ANYTHING ELSE IS UNRECOGNIZABLE 
DIIC 10 DB OH 
DIID C307D1 MP Wl 
DI20 CDOBD2 BOUNDS! CALL —_ HEXNUM 
DI23 EB XCHG 8DE GETS START 
D124 CDOBD2 CALL - HEXNUM 
DI27 EB se : 4DE GETS END, HL GEIS START 
D128 7B ov A 
DI29 95 ‘ABO. 
DI2A 5F “ Mov E,A 
DI2B 7A Moy A.D 
DI2C 9C SBB H 
. DI2D 57 MOV DA 
ies DIZE 13 INK D §DE 1S #0F BYTES TO WRITE 
(N DI2F CEFF : Za C4255 $255 SIGNALS START OF A BLOCK 
D134 4D 
DI35 CDC3D2 CALL —- FDWRT 
DI38 4c MOV CoH 
D139 cocane CALL FDW WRITE THE START ADDRESS 
D13D cDC3D2 CALL —- FOWRT 
DI40 4A Mov C.D 
DI4) CDC3D2 CALL FDWRT ‘PUT OUT THE BYTE COUNT 
Se og ee ————— 
DI44 4E Wi2! = MOV C,M 
DI45 CDC3D2 CALL  FDWRT = sPUT OUT ALL OF THE DATA 
Di48 23 INK H 
49 1 DCX D 
DI4A 7A MOV A.D 
DI4B B3 ORA E 
DI4C ©244D! NZ Wn2 
DI4F OEFE MVE C,254 4s 
DI5) CDC3D2 MVI | »254 4254 SIGNALS THE END OF THE WRITTEN BLOCK 
DI54 C307DI JMP wal SAND AWAIT THE NEXT COMMAND 
Dizi ces Was = CALL ERTYP = SALREADY EXISTS 
Diss oo ro car 
DISC OEFD CLOSIT® MVI C,253 $253 MEANS ; 
Dise cDe302 ime EANS START ADDRESS FOLLOWS 
CALL — HEXNUM 
oI oe “0 CAL et SGET THE STARTING ADDRESS 
6 C3D2 CALL FDW 
Be wy GH 
DC. CALL FDWRT $PUT OUT THE GO ADDRESS 
DI6C C3740! —JMP- ss FILCL~=—s SCLOSE THE FILE 
DI6F OEFC NOGOS —-MVI C,252 $252 MEANS LOAD ONLY 
bI71 coc3pe CALL FOWRT wea at 
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DI74 2130DE FILCLs LXI Y 
DL ay conte th enc STHIS IS THE FILE BUFFER To CLOSE 


DI7A C9 RET #AND RETURN TO THE 
MONITOR 
DI7B 211ADD-—RR2 EDE 
BITE chore Btn TH cory sREDFIL IS THE INPUT BUFFER 
DI8! FAC7DI JM RR4 tNO FILE NAME WAS FOUND 
_ mee a. RR4 tIF NOT PRESENT 
‘A OPNIN 11S IT P 1 

oe EDpAve RRT® ——~€aLL FDREAD %4GET A BYTE FROM THE REGUpD nN? 

) FEF cel #I1S THIS A DATA BLOCK?22 
DI8F CAAIDI JZ BLK 
D192 FEFD Cpl 253 ) 
DI94 CACCDI JZ LUNGO ee DS 
D197 FEFC Cpl 252 #LOAD ONLY? 
be cs RZ ‘ tRETURN ON A LOAD ONLY FILE 
piek meus ae sabi #NOTIFY THE USER THAT THIS IS NOT RUNNABLE CODE 
DI9E C3B2D0 ___ SMP BEGIN $sTEMPORARY ERROR EXIT 
DIA] CDBAD2 REDBLK# CALL FD 
Biel Cau ie READ #GET THE START ADDRESS 
DIAS COBAD2 CALL FDOREAD 
DIA8 67 MOV H,A 
DIA9 CDBAD2 CALL FUREAD 
DIAC 5F MOM E,A $GET THE BYTE COUNT 
DIAD CDBAD2 CALL FDREAD 


DIBO 57 _ Mov” __DyA 


DIB! CDBAD2 = RR28 CALL FUREAD %GET THE DATA 


DIB4 77 MOV MOA SAND TRANSFER IT 

DIB5 23 INX H 

DIBO 1B DCX D 

DIB7 7A Moy A,D 

D1B8 B3 ORA E 

DIB9 C2BIDI __JNZ __RR2 $UNTIL ALL DATA IS MOVED 

DIBC COBAD2 CALL FDREAD sMAKE SURE THIS WORKED 

DIBF FEFE cpl 254 

DICI C2B2D0 Juz BEGIN 

DIC4 C38ADI _JMP—RRI 

DIC7 CDC9D3. -RR4® = CALL_—~—sCEERTYP 

DICA 04 DB ERNSCH 

DICB C9 __RET- sDECLARE NO SUCH FILE EXISTS, AND RETURN 

DICC CDBAD2 LONGO# CALL FDREAD %sGET THE LOAD AND GO ADORESS 

DICF OF MOV L,A 

DIDO CDBAD2 CALL —- FUREAD 

DID3 67 MOY HA 

DI D4 C3F1 D0 JP JJI SAND SET UP TERMINAL CHAR, AND GO 

DID7 CO3CD3. -CHKNAMS CALL = TJ 

DIDA F8 RM $MINUS SET IF NO. NAME IS PRESENT 

DIDB C2v7D! ‘JNZ- — CHKNAM 

DIDE coccD2 CALL FILNAM $GET A FILENAME FROM TI 

DIE! 3E00 MI A,0 SFILNAM SETS CARRY ON FAILURE 

DIE3 3 DCR A $SET THE MINUS 

DIE4 D8 RC SMINUS NOW SET ON FAILURE 

DIES 3C INR A aCLEAR THE MINUS 

DIE6 CDE3D5 CALL  LOKFIL $LOOK FOR THE FILE IN THE DIRECTORY 

DIES CO RET SRETURN WITH CARRY SET, DE DISTURBED 

DIEA OE2A AST® = MI C,’*”  $PROMPT WITH AN ASTERISK 

DIEC CD3D00 CALL CO 

DIEF CD4ED3 CALL =‘ TXTIN 

DIF2 CD3CD3 CALL TI $GET A FULL COMMAND, AND PUT FIRST CHAR IN ACC 

DIF5 F5 PUSH PSN $SAVE THE INITIAL CHARACTER 

DIF6 CD3CD3.  ASTLPS «CALL 

DIF9 FAFFDI JM AST2 

DIFC C2F6DI JNZ ASTLP sWAIT FOR A SPACE 

DIFF FI AST28 = POP PSW 

D200 C9 RE 

201 OEUD CRLF MMVI C,CR ——-STYPE OUT A CR,LF 

D203 CD3DD0 CALL CO 

D206 OEOA Mv CyLF 

aaa ' CALL = CO $REPLACED BY THE ABOVE INSTRUCTION 
' RET $REPLACED BY THE ABOVE INSTRUCTION 


THIS ROUTINE GELS A 16 BIT HEX NUMBER FROM THE TXTIN BUFFER ; 
CARRY IS SEI IF NO NUMBER IS FOUND (FIRST [I CALL IS NON-HEX CHARACTER) 


CARRY IS CLEAR AND HL HAS THE RESULT OF A SUCCESSFUL CONVERSION 
1 TO N HEX #S CAN BE ENTERED, BUT ONLY THE LAST 4 COUNT 


STACK24+(TI) 

DATA QU I=*FHL 

AFHL CHANGED 

: THE RE (0) 
D20B 210000 HEXNUM# LXI H,O sINITIALIZE THE RESULT TO 
D20E CD20D2 CALL FORBIT tGET 4 BITS 
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D21B D212D2 
D21E B7 
D21F C9 


D220 CO3CD3 
D223 D630 


D248 & 
D249 DS 
D24A CDE3D5 
024D DA90D2 


D27D 2A7A08 
D280 7D 
D281 B4 
D282 C266D2 
D285 C38CD2 


sCARRY SEI IF NO # TYPED 


rc 
HEXNI® DAD H sSHIFT HL BY 4 
DAD H 
DaD H 
DAD t 
ORA 
MOV, LsA__ ADD IN THE NEN NYBBLE 
CALL  FORBIT $GET NEXT NY 
JNC HEXNI tADD IN ALL VALID CHARS 
ORA A SCLEAR THE CARRY FOR THIS EXIT 
____keT 
FORBIT! CALL = TI sGET A CHARACTER 
SUI 7% 802 
Rc 
ADL = °U"="G"_ 4 2F? 
RC 
ADL = 6 
JP FOR! SAF 
ADI 7 49-A? 
RC 
s ADI = 10 ‘CORRECT THE BASE 
ee: ae SCLEAR THE CARRY 
RET 


THIS ROUTINE FINDS THE HIGHEST AVAILABLE CONTIGUOUS RAM STARTING 


: AT ZERO. NO RAM IS LEFT CHANGED. THE gg IS RETURNED IN A,B 
¢ ASLO, BsHI, BASFIRST NON-RAM LOCATION-4 
3 THIS IS IN ACCORDANCE WITH THE INTELLAC OtYPE MONITOR 
8 STACK#=2 
4 DATA OUT#AB 
$ ABF CHANGED 
MEMCHKS PUSH H sSAVE HL 
MVI H,O sSTART ON PAGE O 
MEMCI® =MOV AM § A@VALUE 
CMA 
MOV MA sTRY TO STORE THE COMPLIMENT 
CMP M $LF RAM, COMPARISON IS ZERO 
CMA STHIS DOESN’T AFFECT THE Z FLAG 
Moy M,A #NOR DOES THIS, RAM IS RESTORED 
INX H $NOR THIS 
Z MEMCI sRAM IS RESTORED, JUMP IF RAM PRESENT 
MOV BH sELSE, BsHI ADOR 
DCR B sMINUS ONE 
MVI A,OCOH sINTEL SID 
PoP H sONLY A,B CHANGED 
RET 


8 THIS ROUTINE DELETES THE FILE WHOSE BUFFER AREA IS POINTED TO BY HL 


THE MECHANISM OF DELETION IS TO SET THE MSB IN THE FIRST DIRECTORY BYTE 


OF THIS ENTRY (SIGNIFIES DELETED ENTRY). THEN THE LINKED FILE IS TRACED, 
AND THE BLOCKS USED ARE DECLARED AVAILABLE IN THE BLOCK OCCUPANCY BIT MAP 
ON TRACK 2 BLOCK 0. ONLY [HE DIRECTORY AND THE BIT MAP ARE CHANGED. 
STACK#6+( MAPIN, LOKFIL, (2+DIRWRT) » CLRSCT,GDRED, MAPOT) 
* DATA IN HL, ABCF CHANGED 


DELETE® PUSH =H $SAVE D,E,HyL 
PUSH =D SWIPE OUT A,B, CyF 
CALL LOKFIL $FIND THE FILE 
DEL2  s1F NOT FOUND, RETURN WITH NO ACTION 
LDAX =D STRANSFORM THE FIRST BYTE 
ORI = 80H_——s THE MSB SET INDICATES 
Stax 4THAT THIS IS AN INVALID ENTRY 
[XI H,9 —-#DE_HAS DIRECTORY ENTRY 
DAD oD sHL POINTS To THE TRACK 
MOVE, M 
IN oH 
MOV = «Dy $DE IS TRACK, SECTOR 
——PUSH D SSAVE THE POINTER 
CALL DIRWRT $REWRITE THE DELETED DIRECTORY BLOCK 
CALL MAPIN $READ IN THE MAP FOR THIS DISK 
pop) SRESTORE THE POINTER INTO HL 
LXI = -D,0- SREVERSE LINK TO [HE DIRECTORY 
DELIs PUSH =H SSAVE NEXT BLOCK ID 
PUSH SSAVE CURRENT BLOCK ID 
SHLD  TRKWNT $PREPARE TO READ NEXT BLOCK 
CALL  GURED $READ THE NEXT BLOCK 
Pop =D SREMEMBER LAST BLOCK 
LHLD = RRYLNK $GET REVERSE POINTER 
CALL COMPAR #THEY SHOULD BE EQUAL 
pops ‘THIS IS NOW CURRENT BLOCK ID 
—JNZ = DEL3_— 4 JUMP “IF REVERSE LINK ABSENT 
CALL  CLRSCT ‘ELSE, CLEAR THE BIT IN THE BIT MAP 
XCHG SDE 15 NEW REVERSE LINK TO NEXT BLOCK 
__LHLD = REWLNK = SNEXT BLOCK 
MOV AL) SIS IT THE END? 
ORR H 
JNZ “DELI. = NO, GET THE NEXT BLOCK 
JMP = DEL4-—s sYES, COMPLETE THE DELETE 


D2BA E5 
D2BB 211ADD 
bL2BE CD34D4 
D2ci El 


D2zc2 CP 


D2C3 E5 
D2C4 2130DE 
D2C7 CD22D4 
D2CA El 
D2CB C9 


D2cc cS 
D2CD D5 
D2CE E5 
D2CF 012009 


D2D2 7! 
D2D3 23 
D2D4 05 
D2D5 C2D2D2 
D2D8 70 


D2D9 El 
D2DA E5 
D2DB CD3CD3 
D2DE CADBD2 
D2E1 FA34D3 


DEL3* CALL ERTYP ‘DELETED PARTIA 
PRIDEL TIAL FILE WARNING 


OB 
DEL4s CALL MAPOT ==sEND, OUTPUT THE UPDATED MAP 
ORA A sCLEAR =) 
seios : THE CARRY TO INDICATE SUCCESS 
PoP H 
RET 


§ THIS ROUTINE RENAMES THE FILE WHOSE BUFFER AREA IS POINT 
€D To BY HL 
$ TO THE NAME STORED IN THE BUFFER AR 
8 STACK=8¢(LOKFIL,MOVLOP, DIRWRT) Pa SSIES, EE Pe 
DATA IN HL, DE 
$ A,F CHANGED 


RENAMEs PUSH B sSAVE BCDEHL 
PUSH D §LOSE AF 
PUSH H 
CALL REN2 
PoP H 
PoP D 
Pap B 
RET 

REN2: PUSH H 
bop B sBC IS OLD NAME 
XCHG sHL IS NEW NAME 
CALL LOKFIL $sPRBSENT ALREADY? 
~ SASSURE ALL ERRORS RETURN WITH CARRY SET 
PUSH B sNOPE 
PUSH H 
Pap B 
PoP H $BC<——>HL 
CALL LOKFIL sOLD FILE EXISTS? 
RC SNOPE, END!! 
PUSH B 
PoP H sHL POINTS TO NEW NAME 
LXx1 B,9 MOVE 9 LETTERS, ALL OTHER PARAMS STAY THE SAME 


CALL DIRWRT 4RBEWRITE THE DIRECTORY 
ORA A sCLEAR CARRY 
ReT sAND QUIT 


$ THIS ROUTINE PERFORMS A BYTIN FROM THE SYSTEM BUFFER (REDFIL). 

$ IT IS USED JUST AS BYTIN IS USED, BUT WITHOUT HAVING TO LOAD HL 
8 STACK=4+(BYTIN) 
‘ 
i] 


DATA OUT A 
AF CHANGED 
FDREAD: PUSH H 
LXI H,REDFIL 
CALL BYTIN 
POP H 


= RET 


$ THIS ROUTINE PERFORMS A BYTOT TO THE SYSTEM BUFFER (WRIFIL). 

s IT IS USED JUST AS BYTOT IS USED, BUT WITHOUT HAVING TO LOAD HL 
8 STACK=4+(BYLOT) 

s DATA INC 

s F CHANGED 


FDWRTS PUSH H 
LXI H,WRTFIL 


CALL BYTOT 
PoP H 
RET 


THIS ROUTINE DECODES A STANDARD FILE SPECIFICATION FROM THE TXTIN BUFFER 
STREAM. THE 10 BYTE DECODED IDENTIFIER STRING IS PUT INTO THE 10 BYTES 
POINTED TO BY AND FOLLOWING HL (M, Mtl, oe. M#9). IF THE FILE SPECIFIER 
FOUND WAS INCORRECTLY IDENTIFIED, THEN THE CARRY BIT IS SET ON RETURN 


STACK =8+(TI,ERTYP) 


DATA QUT F 
AF CHANGED 
FILNAM® PUSH B SAVE MOST REGS 
PUSH D 
PUSH H 
LX! B, 9256+" ¢ 1Ba9,Ca’ ¢ 
FIL2s MOV M,C $FILL WITH DEFAULT SPACES 
INX H 
DCR B 
JNZ FIL2 sFIRST 9 
MOV M,B $FOLLOWED BY DEVICE 0 
POP H 
PUSH H sRESTORE 
FIL38 CALL TI sSKIP SPACES 
JZ FIL3 
JM ERFIL  $sERROR IF NO FILE NAME PRESENT 
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D2E4.01 2E06 


D2E7 77 
D2E8 23 
D2E9 CO3CD3 
D2EC FE3A 
D2EE CAI8D3 
D2F1 05 
D2F2 FAE9D2 
D2F5 B9 
D2F6 FA2FD3 
D2F9 C2E7D2 


D2FC El 
D2FD & 
D2FE 110300 
D301 19 
D302 19 


D303 CD3CD3 
D306 B9 
D307 FA2FD3 
D30A FE3A 
D30C CAI8D3 
D30F 1D 
D310 FAU3D3 
D313 77 
D314 23 
D315 C303D3 


D318 El 
D319 E5 
D31A 110900 
D3ID 19 
D31E CD3CD3 
D321 DE30 
D323 FA34D3 
D326 FEOS 
D328 F234D3 
D32B 77 


D32C CD3CD3 
D32F B7 
D330 EI 
D331 DI 
D332 Cl 
D333 C9 


D334 CDC9D3 
D337 09 
D338 37 
D339 C330D3 


D343 CA4AD3 
D346 23 
D347 22EAD9 
D34A FE20 
D34C El 
D34D CO 


D34E C5 
D34F D5 
D350 E5 
D351 21ECD9 
D354 22EAD9 
0357 CD37D0 
D35A FE7TF 
D35C CA85D3 


LXI B,6*2564 §B=6 CHARS, <C#CR,LF,’ 7, OR 7% 
FIL4s = MOY MA sSTORE THE CHARACTER 
INX H 
FILSs CALL TI sGET NEXT CHAR 
cpl eae 
Jz FIL7 = s#=DEVICE # FOLLOWS 
DCR B 
JM FILS sIF PAST 0, SKIP UP TO 128 
ie FILe 
JM : 
JNZ FIL4 IF NOT «, GET NEXT CHAR 
0 H 
PUSH H +. FOUND, GET .EXf POINTER 
XI D3 
DAD D 
DAD D uM IS EXT 
FIL68 CALL TI SGET CHAR 
CMP c 
JM FIL8 = sQUIT IF EONAM 
Cpl 4a? 
JZ FIL7 — $CHECK FOR DEVICE # PRESENT 
DCR E 
—~ JM FIL6 
Moy MOA 
INX H SSTORE, UP THE POINTER, CONTINUE 
JMP FIL6 
FIL7s = Pap H 
PUSH =H 
I D9 
DAD D $M IS DEVICE # 
CALL TI 
SBI 0" 10-7 
JM ERFIL &NOPE 
cpl 8 
Jp ERFIL 
MOV MA 
CALL TI 
FIL8! RA A $SET THE FLAGS AND A IS THE TERMINATOR 
FIL92 = PUP H 
PoP D 
PoP B 
RET 
ERFIL! CALL  ERTYP 
DB ERFNM 
STC 
JMP FILO 


EACH CALL To TI. (AFTER AN INITIAL CALL TO TXTIN) RETURNS THE NEXT CHARACTER 


JUST AS IN A CI CALL. SUCCESSIVE CALLS PAST THE END OF THE BUFFER RETURN ONLY 
A (CR). BEFORE RETURNING FROM TI, A “CPI 20H’ IS PERFORMED. THIS SETS UP 
Le ia FOR END OF LINE (SIGN SET To MINUS) OR SPACE (ZERO TRUE) DETECTION. 
¢ STACK=2 
¢ DATA OUT#AF 


§ 
~—¥ FROM THE BUFFERED INPUT STREAM. THE CHARACTER IS RETURNED IN THE ACCUMULATOR 
s 
$ 
$ 


§ AF CHANGED 
TIs PUSH H SAVE THE REGS 
LHLD TXTPNT ‘sGET THE POINTER 
MOV A.M 
cpl CR 
JZ Tl 
INX H 
SHLD TXTPNT ‘sGET THE NEXT CHARACTER AND UP THE POINTER 
TIla rts 4 ¢ SRETURNS WITH Z TRUE IF SPACE, M TRUE IF CR, LF. 
RET 


CALLING TXTIN BUFFERS ONE LINE UP TO {TBFLNG) CHARACTERS LONG. THE 
CHARACTERS ARE BUFFERED IN FROM THE.CI ROUTINE. CHARACTERS ARE ECHOED 
BACK TO. THE CO ROUTINE. AS THEY ARE ENTERED. RUBQUT REMOVES A CHARACTER 
FROM THE BUFFER, AND ECHOES THE CHARACTER REMOVED (WITH THE MSB SET) To 
THE CO ROUTINE. (CONTROL R) CAUSES THE LINE TO BE RETYPED IN EDITED FORM 
(CONTROL X) CAUSES THE BUFFER TO BE CLEARED AND START TXTIN OVER. 

RETURN OR LINE FEED CAUSE END OF BUFFER AND RETURN TO CALLING PROGRAM. 
STACK #8+(C1,CO, CRLF) : 


A,F CHANGED 
TXTINs PUSH B #SAVE THE REGS 
PUSH D 
PUSH H 
TXTA® = LXI H, TXTBUF RESET THE POINTER 
TXTBs SHLD TXTPNT 
TXTLPs CALL Cl «GET AN INPUT CHARACTER 
Cpl RUBOUT 
JZ RUBONE $sRUBOUT A CHARACTER 


23 
C354D3 


2AEADY 
3EEC 


CD0ID2 
C351D3 


CD01D2 
2) ECD9 
3AEAD9 
95 
CA27D3 
4E 
CO3D00 
23 
C3A8D3 


4352524 ERMES! DB 


cel -eontg CO 
Jz RUBLIN $RUBOUT A WHOLE LINE 


CPI CONTR 
J2 RETYP SRETYPE THE CURRENT LINE 
Cpl CR 
JZ EQTXT  sDELIMITER 
Crl LF 
JZ EOTXT +DELIMITER 
LHLD TXTPNT $LEGAL CHARACTER, GET THE POINTER 
MOV MA sSTORE IT 
MOV C,A 
(CALL co sTYPE IT 
} his pLeee eur eer eee! AND OFFH SARE WE WITHIN 2 OF BUFFER FULL? 
\ Je EQIXT $sYEP, END THE TEXT 
| INX H SNOPE, UP THE COUNTER 
| JMP TXTB 
RUBONEs LHLD TXTPNT sGET THE CURRENT POINTER 
MVI A,TXTBUF AND OFFH sGET [THE START OF BUFFER ADDRESS 
SUB L $IF WE HAVE EXCEEDED THAT, THEN 
JZ TXTLP = sIGNORE THE RUBOUT 
DCX H sELSE, BACK UP 
SHLD TXTPNT 
MOV AM $GET THE CHARACTER 
ORI 80H SRUBOUTS HAVE HIGH BIT SET 
MOY CA 
CALL co sECHO IT 
JMP TXTLP 8G0 AGAIN 
RUBLIN® CALL CRLF sD0 A CRLF 
JMP TXTA sAND START AGAIN 
RETYP® CALL CRLF sD0 A CRLF 
XI H, TXTBUF SBEGINING OF DATA TO TYPE 
RETY2* LDA TXTPNT $LOWER BYTE OF END ADDRESS 
SUB L sARE WE THERE YET? 
JZ TXTLP) = 8YEP, CONTINUE 
MOY cM NOPE, TYPE IT 
CALL co 
INX H sUP THE POINTER 
JMP RETY2 %AND AGAIN 


EOTXT#® CALL CRLF SEND OF TEXT, PUT IN A CR, LF 


$ THIS ROUTINE-TYPES OUT AN ERROR MESSAGE TO [HE USER, 
$ IT IS CALLED INTERNALLY AS# 


‘ CALL ERTYP 

‘ DB x 

§ THE RESULT IS THE TYPING OF8 
$ ERROR X 


$ ON THE CO DEVICE, WHERE X IS A 2 DIGIT HEX NUMBER 
§ STACK#I04( TXTYP,(2+*BYTYP) ,(2¢CRLF)) 


s O CHANGED 

ERTYPs XTHL 
PUSH PSW 
PUSH B 
PUSH D 
MOV A,M 
INX H 
PUSH H 
PUSH PSW 
LXI H,ERMES 
CALL TXTYP 
PoP Pow 


SIA LSTERR 


CALL CRLF 
POP H 
POP D 
Pop B 
POP PSW 
XTHL 

RET 


“ERROY , “R47 4128 


§ THIS ROUTINE TYPES OUT A SPACE, AND THE HEX BYTE IN A UPON ENTRY 


4 STACK#64C0 
+ AF CHANGED 
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———— earl’, yoYv Ay& ' 
*) OTT Oe YT v0 
NITY? |. Daca id bye rw? 


BYTYPs Bus’ PSW 
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D3EC F5 
D3ED 0E20 MVI C47 
D3EF CD3DD0 CALL co 
D3F2 Fl PoP PSW 
D3F3 F5 NMTYP® PUSH pSW 
D3F4 OF RRC 
D3F5 OF RRC 
D3F6 i isp 
7 0 
Dare cD00D4 CALL —_-HEXCHR 
D3FB FI PoP PSW 
D3FC CDUOD4 CALL —-HEXCHR 
D3FF C9 RET 
D400 F5 HEXCHRs PUSH hes 
D401 E60F 
D403 C630 f ADI 0" 
D405 FE3A/“ cpl 79% +1 
D407 DAOCD4 Jc HEX1 
D40A C607 AvI 7Al-"94-1 
D40C 4F HEXIs = MOY CyA 
D40D CO3DD0 CALL co 
D410 Fl Pop PSW 
Dall C9 RET 
THIS ROUTINE TYPES OUT A STRING OF CHARACTERS ONTO THE CO DEVICE. 
; THE STRING QF ASCII CHARACTERS TO BE TYPED STARTS AT M (WHAT HL POINTS To) 
+ AND ENDS EITHER WITH A O, OR WITH THE FIRST CHARACTER FOUND WITH 
$ THE MSB SET. IN THE LATIER CASE, THE MSB IS CLEARED AND THE CHARACTER 
+ IS TYPED. 
s STACK =4+C0 
$ DATA IN HL 
$ AFHL CHANGED 
D412 7E TXTYps Mov AM 
D413 B7 ORA A 
D414 C8 RZ 
D415 F5 PUSH PSW 
D416 E67F ANI 7FH 
D418 4F MOV C,A 
D419 CD3DD0 CALL CO 
D41C FI Pap PSW 
D41D F8 RM 
D41E 23 INX H 
D41F C312D4 JMP TXTYP 
$ THIS ROUTINE PUTS OUT A BYTE (PASSED IN C) INTO A BUFFER 
§ AREA (THE BEGINING OF WHICH IS POINTED TO BY HL 
¢ NO REGISTERS ARE CHANGED. IF THIS BYTE FILLS THE BUFFER, 
$ THEN THE BUFFER IS WRITTEN ONTO THE PROPER. DEVICE. 
§ STACK#=4e<¢ BLKOT) 
$ DATA INC 
$ F CHANGED 
D422 D5 BYTOTs PUSH OD sSAVE D 
D423 E5 oyey psf PUSH OH sUND H 
D424 111400 PYSHPS™ Ly Dy» WRCNT-WRFLNM $0FFSET To THE BYTE COUNT 
/ D427 19 DAD D ©2¢ ‘sHL POINTS To BYTE COUNT 
“0428 34 INR M ¢UP THE BYTE COUNT 
D429 5E ~~ WOv EM $SAVE NEW VALUE IN E 
DA2A 19 DAD D 
DA2B 23 INX H $4COUNT+1 POINTS TO AREA FOR. THIS BYTE 
D42C 71 vir &7 H Mav Mc sSTORE THE BYTE 
D42D E} PVE "| POP H sH HAS THE FILE BUFFER POINTER 
DA2E IC an? Ee INR E sIF BUFFER NOW FULL, E GOES To 0 
D42F CC62 CZ BLKOT $IF SQ, PROPER FORWAT FOR BLOCK QUTPUT CALL 
D432 DI poe PS —pop D #REGS ARE UNDISTURBED 
D433 C9 RET sEND OF BYTE QUT 
- $ THIS ROUTINE BRINGS IN A BYTE (PASSED IN A) FROM THE BUFFER 
§ AREA (POINTED TO BY HL). ONLY A IS CHANGED. CARRY SET FOR EOF 
$ STACK=6+(BLKIN) 
§ DATA OUI A 
$ AF CHANGED 
D434 D5 BYTIN® PUSH D r 
D435 £5 PUSH H #SAVE STUFF, AS ABOVE > ov 9 
a) | vu 
D436 110E00 Y UI DyRFWLNK-RDFLNM 1GET THE FORWARD LINK ogee 
D439 19 DAD D- HL=9144 0° 
/ DA3A 7E MOV A.M s TRACK we r i 
/ D43B 23 INK H @POiITE/ 
k D43C B6 ORA M 8OR SECTOR <> O } - of 
ae Loree See ote — 2 ie WOT THE LAST LINK, THEN NOT EOF! | eae | 
NT-1-RFWLNK=-1 sPOINT To LAS ( wag 
Daas Ip ae a eee LAST BLOCK BYTE COUNT opt 
DCR M sDECREMENT THE BYTE COUNT \ 
D445 C24ED4 JNZ NTEQF 4$IF ONE BYTE PRESENT, M WAS 2 
D448 34 INR M 4IF NONE PRESET, RETURN M TO 1 FOR REPEAT CALLS 
D449 AF XRA A 4ON EOF, RETURN A=O 
D44A 37 SIc #AND CARRY SET 


Se 


§ THIS ROUTINE TRANSFERS A BLOCK OF DATA FROM THE WRITE FILE 
§ BUFFER AREA INTO THE DIRECT OUTPUT AREA. HL POINTS TO THE 
$ WRITE FILE BUFFER AREA, AND NO REGISTERS ARE CHANGED. 

§ STACK#104(UNITGT, (2¢NXTSCT) ,WMB,GDWRT,DUMPUT) 


$ DATA IN HL 
¢ O CHANGED 
BLKOTs PUSH PSW #SAVE ALL REGS 
PUSH B 
PUSH D 
PUSH H tHL MUST BE LAST ON 
roan cernet §GET THE UNIT NUMBER FROM THE BUFFER AREA 


SHLD SCTNXT sTEMPORARY STORAGE 


CALL WMB. SWRITE BYTE MOVE ROUTINE 
LHLD SCTNXT $#HL IS THE NEXT LINKED SECTOR 
SHLD WFALNK = $STORE AS THE FORWARD LINK OF THIS BLOCK 


X CHG +DE IS FWD LINK 

PoP H 

PUSH H sHL IS FILE BUFFER AREA 
_LXI B, TRKWRT-WRFLNM 

-DAD B HL POINTS TO TRACK TO WRITE 


MOV C,M sCURRENT TRACK IS FUTURE REVERSE LINK 


SRESTORE HL 


MOY MoE NEW CURRENT TRACK 
INX H 
MOY BM sCURRENT SECTOR IS FUTURE REVERSE LINK 
MOY M,D sNEW CURRENT SECTOR 
x H 
MOV uC REVERSE LINK 
INX H 
MOV MB 
~INX H S$POINT TO THE BLOCK COUNTER 
INX H 
INX H , #WHICH IS HERE 
INR M #AND UP THE COUNTER BY ONE FOR THE NEXT BLOCK 
JNZ BLK! $BRANCH IF NO OVERFLOW OCCURS eo 
INX H sPOINT TO THE NEXT BYTE 
INR M AND UP THAT COUNTER TOO pu oc 
BLKIs CALL GDWRT  $sCHECKED WRITE OPERATION 
H 
D 
B 
P. 


sSTACK IS RETURNED 


w 
= 


$ THIS ROUTINE TRANSFERS THE BLOCK TO GO OUT FOR A RANDOM BLOCK 
$ FILE TRANSFER. NQ NEXT SECTOR IS SEARCHED FOR!! 
$ STACK#10*(UNITGT, WMB, GDWRT) 


RNDOT® PUSH PSW 
PUSH 


B 
PUSH D 
PUSH H tSAVE ALL REGS 
CALL UNITGT sDECLARE THE DISK 
CALL WMB #MOVE THE INFO 
ALL GDWRT #WRITE THE BLOCK 
Jc ERET $WE MUST RETURN THE STATUS OF THIS WRITE 
POP H 
PoP D 
PoP ; . 
PoP s' 
ORA A aTHIS WAS A SUCCESSFUL WRITE 
RET 


S ROUTINE TRANSFERS ALL OF THE SAME DATA AS DOES THE BLKOT® 
' ROUTINE, BUT DOES NOT FETCH A NEXT SECTOR, BUT PUTS A O INTO THE 


WARD LINK 
: STAChSt U+ (WMB, UNITGT, MAPOT, LOKFIL, DIRWRT, (GDWRT#2)) 


§ O CHANGED 


POP H 
Pop D 
RET 
NTEOFs pop H §FOR SOME REASON, THIS IS NOT THE EOF 
PUSH «HH 4SOQ RESTORE THE BUFFER PO NN 
Lx! D,RDCNT-ROFLNM e TEE OO, SE 
DAD D aj) 3 . 4 72) 
INR M tup THE BYTE CoUNT fo 
"gla SRESTORE HL TO READ FILE BUFFER pol D Or 
ura C2 BLKIN ‘IF NEED BE, DO THE BLOCK INPUR Pet te® 
oes 42H XTHL $RESET HL TO POINT TO THE BYTE COUNTER 
MOV E,M 
DAD D 
INX H tM IS NOW THE BYTE TO READ IN 
MOV AyM 
PoP 
pop D 
ORA OA SCLEAR THE CARRY FOR A SUCCESSFUL READ 
RET tEND OF BYTE IN, AS ABOVE 
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' CLSOTs PUSH  PSW 
bape C8 PUSH B 
mae us 
babs £56006 CALL UNITGT ‘$DETERMINE WHICH URIVE 
D4B8 COEFD4 CALL = WMB #MOVE THE DATA 
D4BB 210000 LXI H,O sH IS O 
D4BE 2261DA SHLD  WFWLNK $S0, NO FORWARD LINK 
D4CI 3A67DA J€ta8WRENT) $GET THE WRITE COUNT (255-254 COUNT#=0-255 BYTES) 
D4C4 C60! or ol sUP | GIVES (1-0 COUNT#0-255 BYTES) 
DAC6 3266DA x WRCNT-! $STORE IN THE EXPANSION BYTES 
D4C9 2A03DA LHLD  =WRCNT=4 $PUT THE BLOCK NUMBER OF THE LAST BLOCK IN A 
DACC E5 PUSH =H $SAVE IT 
DACD CDs! D7 CALL GUWRT ‘WRITE THE DATA 
D4D0 CD58D7 CALL MAPOT ‘OUTPUT THE BITMAP ONLY WHEN CLOSING. THE FILE 
D4D3 Cl Pop B $RECALL FILE LENGIH IN BLOCKS 
D4D6 E1 Pop H #RECALL BUFFER AREA OF FILE 
Dabs COEI05 CALL to IL sTHIS MUST FIND THE FILE 
4D6 A | 
Dabo 310000 i LXI H{13)  sTHIS OFFSET GOES To THE BLOCK COUNT 
D4DC 19 DAD D 
D4D0 71 MOV M,C §STORE THE LOWER 8 BITS OF BLOCK COUNT 
D4DE 78 Mov A,B $GET THE UPPER BITS 
D4DF OF RRC 
D4EO OF RRC #NOW THE 2 MSB“S 
D4E! E6CO ANI OCOH = sQNLY THESE BITS Z 
D4E3 2B D H ; , 
D4E4 2B DCX hy $POINT To THE OVERFLOW BIT AREA (M5 GS OF DAT my 
D4E5 B6 ORA M 
D4E6 77 MOV MA §STORE THE MSB S 
D4E7 CDOEDS CALL DIRWRT SAND WRITE IT 
D4EA El Pap H 
D4EB DI Pop D 
D4EC Cl PoP B 
D4ED FI PoP PSW e an aid J 
- a V 
D4EE CO RET pipprist= napa 58 ; pI raged») 
$ STACK=2 ywaisy = \ a g 100 70 4 
§ DATA IN HL cuNnN 
$ ABCDEF CHANGED move Ba 
D4EF 1153DA WMB! —_LXI D,WRELNM 
D4F2 011501 LX @,WRDAT#Z250-WRFLNM > = SPOINTER AND COUNT FOR TRANSFER 
AF5 EB MOVLOP® XCHG 
D4F6 1A MOVLI8 LUAX OD 
D4F7 77 Moy M.A 
jerks re oe 4 sAND BOOKKEEP “ 
BO MOT | moeE OL US 
: ~ Dex B — Move sae HOF SITE VA 
‘a D4FB 78 MoV A,B 
D4FC BI ORA c 
D4FD C2F6D4 JNZ MOVLI = SCONTINUE UNTIL DONE 
D500 C9 RET $THEN RETURN 
§ THIS ROUTINE READS A BLOCK OF DATA INTO THE DIRECT INPUT AREA, AND THEN 
$ TRANSFERS IT INTO THE DESIRED BUFFER AREA IN RAM. HL POINTS TO THE 
# READ FILE BUFFER AREA, AND NO REGISTERS ARE CHANGED. THE DISK 
# ROUTINES GET THE BLOCK ADDRESS TO READ FROM THE FORWARD LINK OF THE 
$ READ FILE BUFFER AREA. 
8 STACKs10#(UNITGT, ERTYP, (2#GDRED) , (2¢MOVLI)) 
8 DATA IN HL 
$ O CHANGED 
§ TWO ROUTINES, ONE FOR LINKED FILES, AND ONE FOR RANDOMLY ACCESSED FILES 
D501 F5 RNDIN® PUSH PSN THIS IS A RANDOMLY ACCESSED FILE 
D502 3E0! uy A, $NO NEED TO CHECK THE REVERSE LINKAGES 
D504 C30AD5 JMP SEKI $USE THE COMMON PORTION OF THE ROUTINES 
D507 F5 BLKINs PUSH  PSW sSAVE THE REGS 
D508 3E00 MI A,0 
D50A 3236DA BLKIIs STA LNKCNT sSTORE THE LINK/NON-LINK PARAMETER 
D50D C5 PUSH B 
D50E 05 PUSH D 
DSOF E5 PUSH H 
D510 CD60D6 CALL —_—sUNITGT 
D513 010A00 XI B,TRKRED-RDFLNM $POINT TO THE CURRENT TRACK, SECTOR 
bie oe ee 
MOV E,M §SAVE THE CURRENT TRAC 
D518 23 INK H , ee ee 
| p59 56 MoV D,M tIN D,E 
5 PUSH D DONT FORGET THAT THIS IS ON THE STACK 
bie 010300 uxt B. »RFWLNK-TRKRED~! sTHIS IS 3 BYTES 
$HL NOW POINTS TO THE FO 
OAIE ke a as THE FORWARD LINK 
D520 23 INX H 
D522 EB tow |OM 
x $HL IS THE FWDLNK 
bss 3 MOV A,H 
4 BS ORA L $CHECK FOR 8 OCK 
D525 CAG8D5 Jz EOF 1 sFILL IN LAT ER pe ten 
D528 223EDA SHLD. TRKWNT $SET UP THE READ 
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CALL GDRED 4sREAD WITH ALL ATTENDANT RETRIES!! 


MVI s,Q SRESET THE READ COUNT To O 
STA RUCNT —1T0 CORRECT FOR WHATEVER IS WRITTEN 
WREMOVE THIS FROM THE ST 
LOA —-LNKCNT.SMUST THIS FILE HAVE A PROPER REVERSE LINKY OY 
Jz BLKI2 4YES, GO CHECK IT 
POPs 
PUSH | #RESTORE THE POINTER 
»RDFLNM ¥AND THE INPU () WOE 
LX] B RDCHKS*2-RDFLNM Ee ee Cee e 
JMP -BLKI3. STRANSFER AALLLL OF THE DATA 
BLKI2* LXI —_-H, RRVLNK WYES, CHECK IT 
WOV AGM 
SUB C 
MOY E,A E20 IF A REVERSE LINK ERROR OCCURRED 
MOV AgM-—sSA®REVERSE SECTOR 
SUBD §A<>0 IF A REVERSE LINK ERROR OCCURRED 
ORA OE ICHECK FOR EITHER WRONG TRACK OR SECTOR 
JNZ EOF — sERROR FOUND 
POP H 
PUSH SRESTORE THE HL 
LX] BB, TRKRED-RDFLNM $0FFSET To THE TRACK READ 


DAD 
J TRKRED 
FLX =B,RDDAT+256-TRKRED sMOVE THIS MANY BYTES 


pov FON rAKOUR OMT VO (Dut 


seeueald — H CC digph+ daH= 256D+ PCy 
PoP D 42% +06 =\NI4dx P64 = 7DH 
Pup B 
Pap PSN 
ORA A sCLEAR THE CARRY TQ SHOW NO EOF 
RET 

EOFI2 = PUP D #CORRECT THE STACK ERRORS 


EQFs CALL ERTYP 


OB 
ERETs POP 


~~ sTYPE OUT AN END QF FILE ERROR 


POP D 
PoP B 
POP PSW 
sTCc 

RET 


THIS ROUTINE OPENS A FILE FOR INPUT AND ASSOCIATES IT WITH A PARTICULAR 
FILE BUFFER AREA IN MEMORY. HL POINTS TO THE BUFFER AREA, WHICH HAS THE 
FILE NAME TO BE QPENED. RETURN IS WITH CARRY#0 IF QPENED SUCCESSFULLY, 
CARRY#| IF IT FAILED TO OPEN {FILE NOT FOUND). 

STACK#104{ LOKFIL, ERTYP) 


DATA IN HL 
F CHANGED 
OPNIN® PUSH —PSW 
PUSH BB 
PUSH =D 
PUSH =H 
CALL LOKFIL #DOES THIS ALREADY EXIST?? 
JC NTYPR 
PUSH =H ; 
LXI H,9 —- SOFFSET To TRKSCT 
DAD =D 
MOV «E,M—s SE®FIRST TRACK 


H 
MOV D.M sD=FIRST SECTOR 


~~ POP H sRESTORE H= RAM BUFFER 
LXI B, TRK RED-RDFLNM 
AVI f,0 SALL OPEN FILE OPERATIONS GIVE.A CURRENT TRACK 
INX H LAND SECTOR OF ZERO, WITH A FORWARD LINK 
MY I M,O $0F THE FIRST BLOCK 
INX H ; 
INX H : 
INX H SAND POINT HL TO [HE FORWARD LINK 
MOV ME $STORE THE TRACK AND SECTOR 
H 
ae M,D sIN THE FILE BUFFER FADLNK 
ccm © B, RDCNT-RFWLNK-! 
B $HL POINTS TO BYTE COUNT 
o\ COMvL W255) sINIT BYTE COUNT To -1 
POP D 
pop B 
POP PSW 
ORA A 
RET 


NTYPRs CALL ERTYP 
Db 


ERNSCH 
JMP ERET 
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QUTINE OPENS A FILE FOR OUTPUT, AND ASSOCIATES IT WITH A PARTICULAR 
; FILE BUFFER AREA IN MEMORY. HL POINTS TO THE BUFFER AREA, WHICH HAS THE 
¢ FILE NAME TO BE CREATED INT THE DIRECTORY. RETURN IS WITH CARRY#0 IF ° 
# OPENED FOR OUTPUT SUCCESSFULLY, CARRY#! LF IT FAILED TO OPEN SUCCESSFULLY 
¢ (FILE NAME ALREADY PRESENT). 
8 STACK#10+(LOKFIL,PUTFIL, DUMPUT, ERTYP) 
8 
‘ 
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DATA IN HL 
F CHANGED 
D5A8 F5 OPNOT® PUSH = PSW 
D5A9 CS PUSH BB 
D5AA D5 Payee 1 
DeAC CDE3D5 CALL  LOKFIL #IS THIS FILE NAME ALREADY PRESENT?? 
D5AF D2CFD5 INC ARDPR $IF SO, GO TO ALREADY PRESENT 
D5B2 CDI4D6 CALL PUTFIL sIF NOT, THEN STICK IT WHERE 
D5B5 011400 LXI B,MRCNT-WRFLNM = $BYTE COUNT OFFSET 
D588 09 
9 36FF i255 )sINIT THE BYTE COUNT TO -! FOR WRITE START 
DSBB O1FCFF Le as SOFFSET TO THE BLOCK NUMBER 
09 DAD 
OSBF 360! MyI ae 4THIS IS THE FIRST BLOCK 
D5CI 23 INX H s0F A 2 BYTE COUNTER 
D5C2 3600 MVI 0 
D5C4 El POP i $RESTORE HL 
D5C5 E5 P 
D5C6 CDU6D5 CALL DUMPUT sJUST IN CASE, PUT QUT THE EMPTY EOF 
D5C9 El pup H 
DSCA DI s 
D5CB CI pop Ai) 
DSCC FI Pop PSW 2 2. 
DS5CD B7 ORA A cy ae, 
D5CE C9 RET 4 
DSCF COC9D3 ARDPR® CALL ERTYP sTYPE QUT AN ERROR sf 
D5D2 03 DB ERDUP sDUPLICATE EXISTS ay 
D5D3 C36DD5 JuP ERET 50 
19 9C 
D5D6 CDEFDS DUMPUTs CALL MMB 
D5D9 2 
D5DC 2261DA SHLD  WFWLNK $STORE O AS THE FORWARD SECTOR POINTER 
D5DF CD81D7 CALL  GOWRT 
D5E2 C9 RET 
8 DIRECTORY RESIDES ON TRACK 2, SECTORS 2-30 (15 BLOCKS) 
§ 16 BYTES PER EXTRY, 16 ENTRIES PER BLOCK, 240 ENTRIES IN DIRECTORY 
$ BYTE O=0 IMPLIES THERE ARE NO FOLLOWING ENTRIES 
§ BYTE 0>127 MEANS..THIS ENTRY IS ERASED, AVAILABLE FOR REWRITE. 
$ BYTE O-8=FILNAM-EXT 9 BYTES OF ASCII FILE NAME AND EXTENSION. 
8 BYTE 9= TRACK OF FIRST BLOCK 
8 BYTE 10= SECTOR OF FIRST BLOCK 
$ BYTE 11s DAY OF MONTH (1-31) 
§ BYTE 12= MONTH (LS4BITS) YEAR BEYOND 1975 (MS 4 BITS) 
$ BYTE 13= LENGTH OF FILE (0-255 BLOCKS) 
8 BYTE 14-15= RESERVED FOR FUTURE 
¢ ON ENTRY, HL POINTS To THE FILE BUFFER WITH THE NAME TO SEARCH FOR. 
§ THIS READS THE DIRECTORY UNTIL PERFECT MATCH, OR END OF DIRECTORY 
$ IS FOUND. RETURNS DE POINTING TO MATCHING DIRECTORY ENTRY, OR 0. 
§ STACK#84(DI RBLK ,DIROPN,UNITGT) 
$ DATA IN HL 
$ DATA OUT DE 
$ D,E,F CHANGED 
D5E3 F5 LOKFIL! PUSH ~~ PSW #SAVE REGS 
D5E4 C5 PUSH B 
D5E5 E5 PUSH H 
D5E6 CO60D6 CALL —_—;UNITGT 
D5E9 CD77D6 CALL DIROPN $s0PEN THE DIRECTORY TO BE READ IN 
DSEC CD87D6 =NXDRBL! CALL DIRBLK 4GET DE POINTING [Q NEXT ENTRY IN DIRECTORY, 
: ' Jc EODIR  sEND OF DIRECTORY IF CARRY 
DS5EF CAOCD6 Jz NONTRY $IF ZERO, THEN END OF ENTRIES IS FOUND 
D5F2 0609 MYI B,9 $MATCH 9 LETTERS 
D5F4 EI PoP H 
se os pusi H SRESTORE THE HL REGS 
D sAND SAVE THE STARTING 
D5F7 IA NXTLTR# LDAX =D ee 
aa BE CMP rv 
F9 C208D6 JNZ NOMTCH 0 : : 
oe INz N ¢IF NOT THE FILE NAME, THEN JUMP 
DS5FD 13 INX D 
D5FE 05 DCR B 
DSFF C2F7D5 JNZ NXTLTR sCONTINUE FOR 9 LETTERS 
D602 DI Pup ) sAHA!! A MATCH 
D603 E1 pop H 
D604 CI PoP B 
nee a Pop PSW 
ORA A CLEAR CARR 3S ; 
oe ee anh ’ Y MEANS SUCCESS 
D6U8 DI NOMTCH® Pup 


D609 C3ECD5 JMP NXDRBL $#NO MATCH, TSK TSK, TRY THE NEXT ENTRY. 


D60C 110000 NONTRY? LXI D,O $E0D FOUND WITH NO MATCH, RETURN DE=0 
DOOF El POP H 
D610 Cl POP B 
D6ll FI PoP PSW 
pal ae ES sSET CARRY MEANS NOT FOUND 
$ THIS ROUTINE IS ENTERED WITH HL POINT. 
$ CONTAINING THE NAME TO BE ENTERED taro THe Dinccrany mineee 
$ THE ENTRY Is MADE IN THE FIRST EMPTY OR ERASED BLOCK 
§ QF THE DIRECTORY. THE UPDATED DIRECTORY IS REWRITTEN ONTO THE DISK 
: eT EE ee DERE XT SCE) . 
$ O CHANGED 
D614 F5 PUTFIL* PUSH PSW 
Do!I5 CS PUSH B 
D616 D5 PUSH D 
pals eo an 
6 CALL UNITGT sAND GET THE DISK DRIVE U 
D61B CDCOD6 CALL NXTSCT $#GET THE NEXT SECTOR AHEAD OF Tine. 
D61E 2237DA SHLD SCINXT sSTORE THE POINTER IN THE TEMP STORE 
D62! CD77D6 CALL DIROPN) $QOPEN THE DIRECTORY 
D624 CD87D6 = NTHR# a ag sACCESS NEXT ENTRY THRU DE 
$ ODIR sQ0PS? MY DIRECTORY RUNNETH OVER. 
D627 CA2DD6 JZ ENTHR IF PAST THE LAST, THEN ENTER HERE YEE WHO) AB 
D62A F224D6 Jp NTHR ¢JUMP IF MSB NOT SET (CONTAINS A VALID ENTRY) a 
pose ra ENTHR® hte B,9 sYES, ENTER IT HERE 
(0) H 
D630 & PUSH H SRESTORE H 
D631 7E MVNAMS MOV AWM sMOVE THE NAME BYTE BY BYTE. 
D632 12 STAX D 
D633 23 INX H 
D634 13 INX D 
pees ey DCR B 
D6 31D6 JNZ MVNAM = $UNTIL ALL BYTES DONE 
D639 E5 ——~PUSH H 
D63A 2A37DA LHLD SCTNXT sRETRIEVE THE STORED POINTER 
D63D EB XCHG 
D63E 73 MOV M,E sSTORE THE TRACK IN THE DIRECTORY 
D63F 23 INX H 
D640 72 MOV M,D $AND THE SECTOR 
D641 23 ___INK H 
D642 3AE7D9 : LDA DAYOM tGET DAYOFMONTH 
D645 77 MOV M,A 
D646 23 In -H - 
D647 3AE8D9 LDA MOYR $GET MONTH, YEAR 
D64A 77 MOV MAA sPUT INTO DIRECTORY. 
U64B 23 INX H sPOINT TO THE LENGTH COUNTER 
D64C 3600 MVI M,O tAND ZERO THE LENGTH 
D64E El PoP H sRESTORE HL THE FILE BUFFER POINTER 
D64F 23 —INX. H #SKIP PAST THE DEVICE BYTE 
D650 73 ne M,E 
D651 23 NX H 
D652 72 MOV M,D sSTORE THE TRACK AND SECTOR TQ START WIFF. 
D653 23 ENX H 
D654 AF XRA A 
D655 77 MOV M,A #BLOCK ZEKO 
D656 23 INX H 
D657 77 MOV M,A sMEANS NO REVERSE LINKAGE 
D658 CD6ED6 CALL DIRWRT sPLEASE REWRITE THE DIRECTORY BLOCK 
D65B El POP H 
D65C DI POP D 
D65D Cl POP B 
DOSE Fl POP PSW 
D65SF C9 RET 
§ THIS ROUTINE ACCEPTS THE BUFFER POINTER IN HL, AND GOES FORWARD 
3 10. BYTES OF THERE TO FIND THE DEVICE NUMBER (FOR MULTI DISKS). 
4 THE DEVICE NUMBER IS STORED IN DSKWNT, AND CONTROL IS -RETURNED. 
$ STACK=4 
¢ DATA IN HL 
§ DATA QUT (DSKWNT) 
¢ O CHANGED 
D660 C5 UNITGTs fe f sSAVE REGS 
| 
Des2 610900 LXI B,RDDEV-RDFLNM 9 sQFFSET TO THE DEVICE NUMBER 
peed 4G Sov c M 4#C=DEVICE NUMBER 
AE 0) ° 
od 2140DA LxI H,DSKWNT sTHIS IS WHERE TO STORE IT 
D66A 71 MOV M,C STORE IT 
D66B El PoP H 
D66C Cl POP B 
D66D C9 RET 


> : : AREA 
§ THIS ROUTINE MOVES THE UPDATED DIRECTORY BLOCK FROM THE INPUT 
$ INTO THE OUTPUT AREA, AND REWRITES IT, THEREBY UPDATING THE DIRECTORY 


§ STACK#2+4((2+WMB) ,GDWRT) 
4 ABCDEFHL CHANGED 
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D6BA 
D6BB 
DoBC 
D6BD 
DOBE 
D6BF 


216CDB 
COEFD4 
C381D7 


210202 
22 3EDA 


CDi 208 
217108 
2239DA 
cy 


DIRWRTs LXI 
CALL 
JMP 


H,RDFLNM 


WMB 
GUWRT 


¢ STACK=2+(GDRED) 


8 ABCDEFHL 


DIROPNS LXI 
/ SHLD 


'- CALL 


= 
~ 


H,202H 
TRKWNT 


sMOVE THE DATA 
tWITH THE WMB FUNCTION 
SAME AS CALL FOLLOWED BY RET 


Qrowrrs - 


sFIRST TRACK AND SECTOR OF THE DIRECTORY 


sWILL BE READ 
#1T 1S ASSUMED THAT THE DISK. DRIVE NUMBER 
$TO ig la IS FOUND IN DSKWNT 


T 
I fs START POINTER 


¢ STACK#2¢(COMPAR,GDRED,ERTYP) 


$ DATA OUT AFDE 


$ ABCDEFHL CHANGED 


DIRBLKs LHLD 
XI 
DAD 


Jc 
“il LDA of 
1%» ADI ok 
Weer; 
SIA 
prhbd. CALL 


DIRBIs 
DIRB2s CALL 
- | DB 


sTc 
RET 


STACK =0 


DATA OUT F 


DIRBI~-\$WE HAVE NOT EXCEEDED THE BUFFER AREA 
SECWNT \WE HAVE EXCEEDED — 27¢ACKS(24 2) 
2 NEXT SECTO 
2-) *BUT ONLY THIS ONE TRACK 
s00PS, END OF DIRECTORY ; 
SECWNT ELSE, STORE THE NEW SECTOR 5 \c gy xChO 
GDRED STA SECHIN 
Lo ATZKSY) 
sAND SET UP [HE NEW POINTER yw P S 
sSET UP A CONVENIENT STATUS ett 4-07 
$DE HAS THE POINTER <2 Vey 
$SET. THE FLAGS SA TULUAT 
amy? WCF 


ERTYP 
DIRFUL $sSAY SO 
SEND OF DIRECTORY, SET THE CARRY C 


DATA IN DE,HL 


$ ADEFHL CHANGED 


COMPAR? MOV 


A a sTHIS IS THE LAST ENTRY 
6 
, 


6ty 
ENTRY IS 16 BYTES BEYOND 

sHOW DOES THIS COMPAR TO THE END ? 
¢WHEREAT-END 


sDIRECTORY IS FULL 


THIS ROUTINE COMPARES DE TO HL 

RETURN WITH Z SET IF EQUAL os 
RETURN WITH C SET IF DEaHL + * © L 
RETURN WITH C CLEAR IF DE<HL 4L>0" 


SCOMPARE THE MSBYTES FIRST 
SRETURN LF THE ANSWER IS DETERMINED ALREADY 


sCOMPARE THE LSBYTES 
#AND RETURN WITH FLAGS SET 


§ THIS ROUTINE BRINGS THE BIT MAP IN, AND SEARCHES 

$ FOR THE LOWEST BLOCK (TRACK, SECTOR NUMBER) WHICH IS PRESENTLY UNUSED. 
¢ THE BIT IS SET, INDICATING THE BLOCK IS NOW OCCUPIED, AND THE 

$ BLOCK ADDRESS IS RETURNED IN H(SECTOR) AND L(TRACK). 

§ STACK=2¢(MAPIN,ERTYP, 6) 


§ DATA OUL HL 
4 HL CHANGED 


NXTSCT# CALL 
PUSH 
PUSH 
PUSH 


SMALI 8 
SMAL28 PUSH 


MAPIN 
PSW 
B 


i 


¢BRING IN THE DISK RESIDENCY MAP OF THIS DISK! 


THEN SAVE REGS ee 


) aT 
START AT TRACKG™ is 


HP SFOR THE USER TRACKS ¢ ffH¢K COULTER \ 


’ 

B BLOCKS) /gH 416 S PER TRACK 

H,0 "ASTARTING MITH BD eiceis 

H _/ #SAVE THIS TRACK, SECTOR eh ; 

TS2BT” sCONVERT IT TO A WAND. M A: GT 40 dD) = BY 
> Shve THE BIT POT, 

( 1S THE BIT SEL?7? 

SMAL3 Ae | AP \e ITS WOT Sc” 

H : ’ HOIS SUCTION ZACK 

H . Aoye WS : TLS | groer) 

B 4 HAST GLOCK 

SMAL2 . iy; soT LAST 

L viesUP THE TRACK Co 40 wu Tipe? 


(a4 


DCR ic: #DOWN THE COUNTER j 
JNZ SMAL} = $LOOK IN THE NEXT TRACK ~ AU0rir M00 105 


CALL ERTYP = $THIS IS AN OVERFLOW ERROR 


DB FDFUL IS FULL 
a OCKS=1 ) #51 2¢+TRACKS= SHL POINTS TO THE LAS 
te QFLO TO THE LAST BLOCK ey 

SMAL38 MOV A,D ; boS THE BiT BACK 

ORA M » SOT IT 

MOV MA *SET THE BIT To INDICATE OCCUPANCY 

POP H tHL*TRACK AND SECTOR TO USE 
NXT9s PoP D 

POP B 

POP PSW 

RET 


§ THIS ROUTINE GELS THE TRACK, SECTOR IN LH, AND SETS OR CLEARS THE BIT 


IN THE BITMAP 


§ STACK#6+TS2BT 
+ O CHANGED 


CLRSCT: PUSH PSW 


PUSH =H 

CALL TS2BT — sTRANSLATE_ TRACK, SECTOR TO BYTE My BIT A 
+ ol 0 Tr) \ 

ANA M SCLEAR THE BIT 

MOV MAA sINTO THE BIT MAP 

POP H 

POP PSW ah 

RET hte 


/ 


THIS ROUTINE CONVERTS THE TRACK, SECTOR IN LH INTO A BYTE POINTER 


' 
§ (H,L) AND A. SINGLE BIT POSITION (A) 
4 STACK#2 
$ DATA IN HL 
§ DATA OUT AHL 
$ AFHL CHANGED 
TS2BTs PUSH D — 
MOM A Guy Suet & 
RRC 
RRC ) Aue sO 
RRC } 
D~ RRC ae 
ANI ' 
: 3 
7 ll acl avr ae Add L 
AvI (BITMAPS8)-AND OFF bh re RCS 
MOV E,A Se ‘, { rH 11% bar 
MVI 4,0 : Sn nik a An's 
ACI (BITMAP=6)/256  “ 
| Mow DyA NDE 1S THE BITMAP BYTE DESIRED | 
al Ay 
RRC SONLY EVEN SECTORS ARE USED © GH < 
ANI 7 tA IS BIT # DESIRED 
MOV H,A N 
) MvI A, 80H 
Ts3s | RLC SFIRST TIME THRU, A=l 
DCR H 
Jp Ts3 SCONTINUE TIL H GOES NEGATIVE 
| XcHG HHL GETS POINTER [0 BYTE 
Pap — arora cc eh 
RE 


STACK#104(GDRED, (2+MAPOT) MOVLOP) 
O CHANGED 


MAPINS PUSH PSW sSAVE THE STACK 
PUSH B 
PUSH ») 
PUSH H a 


LDA MAPFLG x | 2 


JNC MAPNI 

MOV B,A ¢ 

LDA DSKWNT rn 
CMP B 7) ae 


CALL MAPOT 


7. Oba Ais MF Wan . 
MAPNIS) LXI Hy H,2— STRACK @y SECTOR QO IS THE BIT MAP AREA 


CALL TRAHAN GET IT INTO THE ‘READER BUFFER 
CALL DRED $3 
XI H,RDDAT sAND.MOVE IT INTO THE BIT MAP AREA 
LXI Ds BITCHK VLR 
LXI #2", B ACKS#TRACKS~4 pe ¢ 

( CALL?!‘ MOVEOP—sMOV 150 BYTES 


~LDA____D SKWNT 
STA MAPFLG $REMEMBER WHAT DISK MAP IS CURRENTLY STORED 
H 


] > 


MAPN28 POP 


POP D 
POP B 


135 


136 


——— 


OOFO 
OOFO 


O77 


D781 F3 
D782 0603 
D784 C5 
D785 CD9FD7 


PoP PSW 
RET 

§ STACK#!0¢(GUWRT,MOYLI ) 

# O CHANGED 

MAPOTs PUSH = PSW 
PUSH BB 
txt 44 He #PUT OUT ONTO TRACK 2, SECTOR O 
SHLD TRKWRT 


LOA MAPFLG 60F THE ACTIVE DISK 
w ¢ALL ADDRESSING OF THE DISK IS NOW DONE! 
ixt BARD OVE THE BIT MAP INTO THE WRITE AREA 


A,7! 
STA MAPFLG sINDICATE THAT NO VALID MAP IS CURRENTLY STORED!! 
H 


POP D 
B 
POP PSW RETURN THE STACK 


THESE ARE THE FLOPPY DRIVE I-0 ROUTINES 
= THE ONLY ENTRY POINTS TO THIS SECTION FROM THE ABOVE SOFTWARE ARE® 


GOWRT WRITE OUT A BLOCK 
GDRED READ IN A BLOCK 
INIT MOVE ALL DISKS TO TRACK O 


$ 
] 
] 
i] 
s IF A DIFFERENT DISK DRIVE INTERFACE IS USED, THEN ALL CODE FROM HERE 
$ TO THE END OF THE RONMABLE AREA MUST BE CHANGED TO INCLUDE THE 

$ ALTERNATE (GOWRT, GDRED, INIT) RQUTINES 

i] 


IF NOT MINI $FOR THE FULL SIZE INTERFACE, 
INPORT EQU OFOH 
OTPORT EQU OFOH 

ENDIF 


IF MINI $FOR THE MINI, 
INPORT EQU OEBH sTHE INPORT CLUSTER 
OTPORT EQU OE8H sTHE QUTPORT CLUSTER 


ENDIF 
FDRED. EQU INPORT sDATA FROM THE FLOPPY ; 
FDSTAT EQU INPORT# 1 ¢#STATUS BITS OF THE FLOPPY 
SRTSWE EQU INPORT+2 sREAD THE SRT STATUS WORD 
SRTRR EQU INPORT+3 s INPUTTING THIS RESETS THE. USRT TO LOOK 
FDINAT EQU INPORT+4 sKLUGE TO SYNCHRONIZE TO 32 MICRSECS 
FDWRIT EQU OTPORT $DATA TO BE WRITTEN TO THE FLOPPY 
SRTTFS EQU OTPORT#1 SPORT OF THE DEFAULT CHARACTER 
SRTRSS EQU OTPORT+2 
FDOUT EQU OTPORT+3 SSEND SIGNALS TO THE FLOPPY 
FDOTWT EQU OTPORT#4 #SYNC TO 32 MICROSECS 
LOADHD EQU OTPORT¢5 STHIS COMMANDS LOADS THE HEAD FOR 3.SECONDS 
HDUNLD EQU OTPORT+6 sTHIS FORCES AN IMMEDIATE HEAD UNLOAD 
8 THESE ARE SIGNALS TO FDOUT (DIRECT FLOPPY CONTROLS) 
WCSEL EQU ' SIsTRACK 0-43, O=ITRACK 44-76 
FUREST EQU rs sUSE TO RESET A FILE UNSAFE CONDITION 
DIRIN EQU SLOGICAL OR FOR IN TRACK 
DIROT EQU NOT DIRIN sAND FOR OUT ee 
WRIGAT EQU 10Q sLOGICAL OR TO. START A WRI 
STEPP EQU 200 SLOGICAL OR TO START A Step PULSE 
STEPM EQU NOT STEPP tLOGICAL AND TO STOP THE PULSE 
§ THESE ARE THE DIRECT STATUS LINES QF THE FLOPPY (IN FDSTAT) 
TRKZRO EQU | 
UNSAFE EQU 2 
IF NOT MINI 
FDRDY QU 4 
ENDIF 
SCTR EQU 8 
INDX EQU 10H 


§ THESE ARE VARIOUS PARAMETERS 


SYNCB EQU 81H $THIS IS THE SYNC BYTE FOR START OF TRACK 

LNBUF EQU 256 #LENGTH OF THE BUFFER 

XTRA EQU 22 sEXTRA BYTES FOR HOUSEKEEPING 

LN2SNC EQU LNBUF*X TRA*1 $DISTANCE OF SYNC TO CHECKSUM 

GOWRT® DI #DISABLE THE INTERRUPT TO MAINTAIN CRITICAL TIMING 
MVI B,3 sTRY THIS 4 TIMES BEFORE GIVING UP 

GDWR1I8 PUSH B 


CALL WRT256 $FIRST. WRITE IT 


GDWR2s 


STHIS ROUTINE ASSUMES THAT THE TRACK .AND SECTOR TO BE WRITTEN ARE IN TRKWRT 


CHKWRT $sTHEN CHECK FOR PROPER WRITE 


GUWR2 4IF IT WORKED THE FIRST TIME 
CHKWRT ‘ELSE, ALLOW 2 TRIES sian cia 


B 
sTHIS IS 


SRESTORE STACK, DON’T CHANGE FLAGS 
POSSIBLY A GOOD RETURN 


sIN WHICH CASE THE CARRY SHOULD BE CLEAR 
#SUCCESSFUL WRITE, RETRUN NOW 

B $A BAD WRITE, TRY AGAIN 

GDWRI siF WE STILL HAVE TIME, TRY AGAIN 
ERTYP $ELSE, SIGNAL THE ERROR AND QUIT 


ERWRT 


sCARRY SET FOR. BAD RETURN 


$ AND THE DATA IS ALL IN WRDAT 
WRT2568 LDA 


CLRLOP# 


WRTLOPS 


CALL 


WROEV 
DSKNUM 
H,WRIBUF 


A 

B, 10H 
MAA 

H 

B 
CLRLOP 
M,SYNCB 
TRKWRT 
TRKWNT 


H, WRSNCB 
CHK436 


WRCHKS 
TRKGET 
HEDLOD 
D, LNBUF + 
H WRTBUF 


A 
SRTTFS 
FDBUF 


WRIGAT@¢FUREST — sTURN ON 


C,A 
SCTGET 
AC 
FDOUT 
NOT FURE 


FDOUT 
FDOTWT 


NOT WRTG 
FDOUT 
FDBUF 


sTHIS MUST CONTAIN THE DISK NUMBER!!! 

‘PROCESS ANY UNIT NUMBER CHANGE 
ACLEAR THE CLOCK SYNC BYTES 

sBY FILLING WITH ZEROES 

$16 OF THEM 


$STORE THE SYNC BYTE 


sSET UP THE TRACK AND SECTOR POINTS 

sL IS THE TRACK 

sDON?T ALLOW A WRITE TO TRACK | 

$DON?T ALLOW A WRITE TO TRACK O 
sSTART OF THE CHECKSUM AREA 


#STORE THE CALCULATED CHECKSUM 
* GET THE DESIRED TRACK 
$#LOAD THE HEAD 
XTRA+24 
*BUFFER AREA TO WRITE TO THE DISK 


STRANSMIT A FILL CHAR OF ZERO 

#THE QUT STATUS 

THE WRITE GATE 
sHOLD THE WRITE COMMAND IN C 

#GET THE PROPER SECTOR 


sINIT THE WRITE GATE QUICKLY 
ST #TURN OFF FILE UNSAFE RESET 


tKLUGE AND WAIT FOR READY FOR DATA 


‘AT *TURN OFF THE WRITE GATE 
sNOW 
sTHIS IS THE PRESENT STATUS 


$ THIS ROUTINE PERFORMS A REREAD OF THE SECTOR JUST WRITTEN. 


#RETURN IS WITH Z=O0 IF A READ FAIL OCCURRED, OR IF A READ DIDNT MATCH 


$ THE IMMEDIATE PREVIOUS WRITE. Z=I IS A SUUCCESSFUL WRITE 


CHKWRTs 


CHKWI 8 


CALL 
RNZ 


REDONC 
sRETURN 


sTRY | TIME TO READ IT 
WITH Z#0 ON A BAD ERROR 


H, RDSNCB $SET UP A 256 BYTE COMPARE 
D,WRSNCB 


B,O 

D 

M 

* RETURN 
D 

H 

B 

CHKWI 


$256 ISN“T ALL, BUT IT IS ENOUGH 
#GET WHAT WAS WRITTEN 

sCOMPARE TO WHAT WAS READ 

ON AN ERROR 


sUP THE POINTERS 


#SUCCESSFUL RETURN, Z=! 


4THIS ROUTINE TRIES 3.TIMES TO READ, THEN JOGS IN, AND QUT AND AGAIN 


GDREDs 


TRY 3RD 


DISABLE THE INTEHRUPT FOR CRITICAL TIMING 
ITRY 3 TIMES TO READ THE BLOCK 


sIF SUCCESSFUL, THEN RETURN 


TRAKIN 
TRY 3RD 


TRAKOT 
TRY3RD 


ERTYP 


JOG _IN 
STHREE MORE 


tag r CHANCE COWBOY 

aLa 

$IF FINALLY SUCCESSFUL, THEN RETURN 
SIF NOT, THEN TYPE OUT. THE ERROR 
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D828 O01 OB ERRED 


0829 CD RET 
§ THIS ROUTINE TRIES TO READ THREE TIMES, RETURNS Zs! FLAG IF OK ON READ 

DA2A 3E02 TRY3RD* MVI A,2 SACTUALLY TRY 3 TIMES 

D82C 323BDA STA REDTRY $HOLD ONTO IT 

D82F CD4808 TRGP® CALL REDONC $#TRY IT JUST ONCE 

D832 C240D8 JNZ TRG! §CRC ERROR, TRY AGAIN?? 

D835 3A3EDA LDA TRKWNT $CRC OK, CORRECT TRACK?? 

0838 217608 LXI H, TRKRED 

D83B 96 SUB M §DESIRED MINUS READ 

DE3C CB RZ s1F ZERO, OKEY DOKEY AND RETURN 

D83D CD22D9 CALL INIT  SELSE, ZERO ALL DISKS AND TRY AGAIN 

D840 213BDA TRGI® LXI H,REDTRY 

D843 35 DCR M ; 

0644 F8 RM $1F TOO MANY, THEN RETURN Z=0 

D845 C32FD8 JMP TRGP STRY TRY AGAIN, AGAIN 


STHIS ROUTINE TRIES ONLY ONCE (AND I DON’T BLAME IT ATALL) 
D848 3A40DA REDONCS LDA DSKWNT ‘$sTHIS MUST CONTAIN THE DISK NUMBER!! 


D84B CDC6D8 CALL DSKNUM $PROCESS ANY UNIT CHANGE 
D84E CD7FD9 CALL TRKGET #GET THE TRACK 
DB51 COB6D9 CALL HEDLOD $LOAD THE HEAD 
D854 CDC7D9 CALL SCTGET sGET THE PROPER SECTRO, AND THEN WAIT 
D857 I11A0) LXI D, LNBUF#eX TRA+4 
D85A 216BDB LXI H,RDSNCB sPOINT TO THE BUFFER AREA 
D65D 3E8) MVI A,SYNCB $PROMPT THE USRT WITH WHAT TO EXPECT 
D85F D3F2 QUT SRTRSS $sSHOVE IT 
D86) DBF3 IN SRTRR  $RESET THE USRT TO LOOK FOR THE SYNCB 
MVI B,255  sEFFECTIVELY ACCOMPLISHED BY SCTGET 
D863 DBF2 STLOPs IN SRTSWE sINPUT THE SRT STATUS WORD 
D865 E601 ANI ' sAND WITH RECIEVER READY 
D867 C272p8 JNZ REDL! SIF READY, GO INTO MIDOLE OF Loop 
DB6A 05 DCR B $IF NOT READY, WAIT FOR 255 CYCLES 
D86B C263D8 JNZ SITLOP $sAND TRY AGAIN 
D86E 05 DCR B IF WE GET HERE, THEN NO SYNC BYTE WAS FOUND 
D86F C9 RET *THE LAST INSTR SET Z FLAG NOT ZERO, SO READ ERROR. 
D870 DBF4 re IN FDINWT sSPECIAL SYNC KLUGE TO HOLD ONTO THE BUD 
D872 DBFO REDL2: IN FDRED ‘sUNTIL DATA IS AVAILABLE 
D874 77 Moy MA 
D875 23 INX H 
D676 1B DCX 1) 
D877 7A MOV A.D 
D878 B3 ORA 
D879 C270D8 JNZ REDLOP 
D87C 21 6BDB LXxI H, RDSNCB sPOINT TO THE BUFFER AREA 
D87F CD6ED8 CALL CHK436 
oe are a eg sGET THE NUMBER OF THIS DISK, 
SAND STORE IT IN THE READ AREA FOR FUTURE USE 
D888 2A82DC LHLD RDCHKS $sHL HAS THE CHECKSUM 
D&8B C3BAD6 JMP COMPAR 
8 CALL COMPARE sTHESE TWO. INSTRUCTIONS ARE 
8 RET 4EFFECTIVELY DONE BY THE JMP ABOVE 
$ THIS Ph DOES A 16 BIT CRC (FROM 
Dé8E 01160) cHKA3e BsLNBUP*X Sak ROM THE INTEL USERS LIBRARY) 
D891 110000 CHKSUMS Lxt D,O 
0894 7E CHKLOP® MOV AM *¢GET THE BYTE TO SUM 
Da9s E5 PUSH H 
D896 C5 PUSH B sSAVE ALL THE REGS. 
0897 AB XRA E 
D698 47 MOV B.A 
D899 OF RRC 
D89A OF RRC 
D89B OF RRC 
D89C OF RRC 
D89D 4F MOV CA 
DG9E AS XRA 
D89F E6FO ANI OFOH 
DBA! AA XRA 
D8A2 6F MOV L.A 
D8A3 79 MOV A,Cc 
D8A4 07 RLC 
DBAS E6IF ANI 1FH 
D8A7 AD XRA L 
“‘D8A8 6F MOV L,A 
D8A9 78 MOV A,B 
D8AA 07 RLC 
D8AB E60) ANI | 
D6AD AA XRA D 
DBAE AD XRA L 
D8AF 57 MOV DA 
D8BO 79 Mov A.C 
D8B! E6UF ANI OFH 
D8B3 A8 XRA B 
D8B4 5F MOV E,A 
D8B5 79 MOV A,C 
D8B6 A8 XRA B 
D8B7 07 RLC 
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D8B8 E6EO ANI OEOH 


D8BA AB XRA E 

D8BB 5F MOV E,A 

D8BC CI PoP B 

D8BD El Pop H 

D8BE 23 INX H 

D8BF OB DCX B 

D8CO 78 MOV A,B 

i 

8 JNZ CHKLOP = $NEXT 
DBC5 C9 RET $NEXT BYTE IF NOT YET DONE 


STHIS ROUTINE IS ENTERED WITH A CONTAINING THE NUMBER 0) 

$ DISK DRIVE UNIT ON WHICH THE DESIRED OPERATIONS ARE 10 BE PERFORMED 
(O-DSKLIM—1). IF THE LAST.DRIVE USED WAS .THIS DRIVE, THEN : 
RETURN IS IMMEDIATE, AND NO ACTION IS TAKEN. IF A NEW DRIVE 

IS CALLED, THEN THE HEAD OF THE PRESENT DRIVE IS FORCED TO UNLOAD 
AND THE CURRENT TRACK NUMBER ASSOCIATED WITH IT IS STORED. 

THE NEW DISK’S LAST TRACK IS REMEMBERED, AND IF VALID, CONTROL IS 
RETURNED. ELSE, THE NEW DISK IS INITED, AND THE TRACK O IS FOUND. 


D8C6 FEOS DSKNUM# CPI DSKLIM 80-7 IS CONDITIONALLY ACC 
D8C8 D2) DD9 JNC DSKRI #NO SUCH DISK EXISTS!! cima 
D8CB 212DDA LXI H,LSTUSK POINTER TO THE LAST DISK 
D8CE BE CMP M sNEW=0LD? 
DSCF C RZ sIF SQ, THEN RETURN NO ACTION 
D8DO F5 PUSH PSW sELSE, SAVE THE NEEDED DATA 
pote a PUSH H 
Moy AM §WAS THE OLD ONE LEGAL? 
D8D3 FEOS CPI DSKLIM 
08D5 D2EID8 JNC DSKNI eIF NOT, DON?T STORE THE OLD TRACK 
D8D8 4E MOV CiM tC#LAST NUMBER 
D8D9 0600 MYI B,O 
D8DB 09 DaD B 
OB8DC 23 INX H sHL=#LSTDSK+#0LD DISK+1 
D8DD 3A3DDA LUA TRAKNO 
D8EO 77 MoV MA sSTORE THE OLD CURRENT TRACK NUMBER 
DSE! D3F6 DSKNI# QUT HDUNLD $FORCE THE HEAD TO UNLOAD 
DBE3 EI Pap H 
D6E4 FI POP PSW sRETRIEVE THE OLD DATA 
D8E5 77 MOV MAA sSTORE THE NEW NUMBER AS THE OLD ONE 
DSE6 4F MOV C,A +BC=NEXT DISK 
D8E7 OF RRC 
D8E8 OF RRC 
DSE9 OF RRC § ASNEWTRACK #32 
D8EA 323CDA STA FDBUF sCQNSIDER.THJS THE NEXT DRIVE COMMAND 
D8ED D3F3 OUT FDOUT $SET UP AHEAD OF TIME TO DEGLITCH 
IF NOT MINI 
D8EF DBF! IN FDSTAT sCHECK THE STATUS QF THIS DISK 
D8FI E604 ANI FDRDY $#1S IT LOADED AND USEFUL? 
ENDIF 
IF MINI 
CALL FDRDY 
ENDIF 
D8F3 C2! D09 JNZ DSKRI $NO, TELL USER ABOUT ITI 
D6F6 09 DAD B 
D8F7 23 INX H 
D8F8 7E MOV A,M 4THIS IS WHERE THE DISK WAS LEFT 
D8F9 323DDA STA TRAKNO ‘$DECLARE IT THE CURKEN COUNT 
D8FC FE4D Cpl TRACKS 81S IT A PROPER TRACK FOR THIS DISK UNIT?? 
D8FE FS RM 
D8FF CD4AD9 GTRKOs CALL TRAKIN 
D902 CO4AD9 CALL TRAKIN 
D905 CD4AD9 ar Lica 
8 CO4A CA R 
D9OB roo MvI D,TRACKS+30 *THIS IS A LARGE ENOUGH EXCESS TO ASSURE 


sTHAT WE WILL GET TO TRACK O (IF DISK PRESENT) 


D90D CO59D9 + TRZLP# CALL TRAKOT 
D910 15 DCR D SSHOULD WE HAVE GOTTEN THERE YET?? 


Doll Fe RM SYES11 RETURN BECAUSE A BAD DISK PROBLEM OCCURRRED 
D912 DBF! IN FDSTAT 
D914 E601 ANI TRKZRO 
D916 C20D09 JNZ - TRZLP 
D919 323DDA STA TRAKNO 
D9IC CP NODSKs RET 
D9ID CDC9D3. ~DSKRI4 CALL ERTYP sD1SK NUMBER >7 
D920 08 DB ERDKNM 
D921 C9 RET ve 
D922 3EFF INIT! AVI A, 
D924 322DDA SIA LSTDSK 
p927 3c 
A ‘THIS IS THE DISK . 
boop OF SE Tie fa SIF THE DISK DOESN’T EXIST, DONT RESET IT 
D92A OF RRC 
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D92B OF RRC 


D92C D3F3 QuT FDOUT sSELECT THE DISK 
IF a 
BFI IN FDSTAT sGE ; 
D930 £604 ANI FORDY  #READY? 
ENDIF 
IF MINI 
CALL —- FDRDY 
ENDIF 
D932 78 MoV A,B $RESTORE THE DISK NUMBER, DON’T CHANGE THE FLAGS 
D933 F5 PUSH — PSW $AND SAVE THE DISK NUMBEP 
D934 0C43D9 cz DKINT 4YEP, GO TO TRACK ZERO 
0937 Fi POP PSN 
D938 3C INR A 
D939 FEOS cpr DSKLIN 
938 C228D9 
DOSE raed XRA A 4AFTER ALL OF THE DISKS RESET, 
D93F CDC6D8 CALL DSKNUM #G0 BACK TO DISK ZERO 
D942 C9 RET 
D943 CDC6D8 DKINT® CALL DSKNUM 
D946 COFFDS CALL  GTRKO 
D949 CO RET 
IF MINI 
FDRDYs QUT LOADHD sTHIS MAKES SURE THAT THE DISK IS ROTATING 
PUSH =D $SAVE ALL REGS BUT THE ACCUM 
LX] D,2000 %2,000 PASSES 
FoRDI® IN FUSTAT %GET THE DISK STATUS 
ANI SCTR  4sTHIS IS A CHECK FOR DISK PRESENT AND ROTATING 
Jz ISRDY sJUMP OUT IF IT IS READY 
DCX D 
MOY AE 
ORA D tHAYE WE DONE 10,0007 
JNZ FDRD| = sNOPE 
DCR A sYEP, SET UP THE FLAGS 
ISRDY® PUP D 
RET SAND RETURN 
ENDIF 
§ THESE ROUTINES FIND THE PROPER DISK ENABLED, THE CURRENT TRACK QF THIS 
§ DISK IN TRAKNO (FOR UPDATING). THE DISK HEAD IS MOVED IN (+1 TRACK, TOWARDS 
’ THE | HUB) BY TRAKIN, AND MOVED OUT (=! TRACK, TOWARDS THE CIRCUMFERENCE) BY 
’ oT. 
8 STACK=2 
§ DATA IN (TRAKNO) 
$ DATA OUT (TRAKNO) 
D94A 213DDA TRAKIN® LXI H, TRAKNO 
D94D 34 INR M sCOUNT UP ONE TRACK 
D94E 3A3CDA LDA FDBUF 
D95! F604 oRI DIRIN 
D953 323CDA STA FDBUF 
D956 C365D9 JMP TRAKMY 
D959 213DDA TRAKOTs LXI H,TRAKNO 
D95C 35 DCR w sCOUNT DOWN THE TRACK 
D95D 3A3CDA LDA FDBUF 
D960 E6FB ANI DIROT  4sCLEAR FOR AN OUT .MOVE 
D962 323CDA STA FDBUF #SAVE IT 
D965 F610 TRAKMVs ORI STEPP 4sSET THE STEP BIT 
D967 D3F3 OUT FOOUT $AND THE START BIT 
D969 EOEF ANI STEPM 4sCLEAK STEP BIT 
D96B D3F3 OUT FDOUT 
D96D CD7ID9 CALL TENMIL $WAIT TEN NILSECS 
D970 C9 RET 
STHIS ROUTINE IS JUST A SOFTWARE 10MS WAIT 
TENMIL® 
IF MINI 
LXI_ BB, 60000 
ENDIF 
IF NOT MINI 
D971 010004 LXI B,2000Q 
ENDIF 
D974 AF XRA A 
D975 OB TMLP® DCX B 
D976 B9 CMP c 
D977 C275D9 JNZ TMLP 
D97A B8 CMP B 
D97B C275D9 JNZ TMLP 
D97E C9 RET 


§THIS ROUTINE GETS THE DESIRED TRACK (FO 

§ STACK#2+(TRAKOT, TRAKIN) Sha ene 
$ DATA IN (TRKWNT), (TRAKNO) 

¢ DATA OUT PHYSICAL 

§ A,B,C,D,F,H,L CHANGED 
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D97F 3A3EDA 


D985 47 


D9E1! CADDD9 
D9E4 C3D4D9 


D9E7 01 


TRKGET2 LDA TRKWNT $GET THE DESIRED TRACK NUMBER 


CPI TRACKS 
RP sERROR 
MOV B,A SAVE TRKWNT 
LXI H, FDBUF 
MOY AM 
ANI NOT WCSEL 
MOV MA 
MOV A,B 
SBI 540 
JP TGETLP 
MOV A.M 
ORI WCSEL 
MON MA 
LDA TRAKNO 
CMP B 41S THE TRACK ALREADY WHERE WE WANT 1T??2 
RZ sYEP, NO ACTION 
TGETLPs LDA TRAKNO $GET THE PRESENT TRACK NUMBER 
MOV B,A $B IS WHERE WE ARE AT 
a arene $A IS WHERE WE WANT TO BE 
Cc 
JZ TENMIL $ONE MORE. SETTLING DELAY BEFORE R 
JP INGIN $A>B THEN GO IN ania 
CALL TRAKOT $A.<B, THEN OUT 


J 
INGIN® CALL TRAKIN 


STHIS ROUTINE LOADS THE HEAD AND WAITS 30 MS FOR SETTLING 
§ IF THE HEAD IS ALREADY LOADED, RETURN IS IMMEDIATE 

s STACK=0 

§ DATA OUT CHRONOLOGICAL AND PHYSICAL 

§ A,B,C,D,F CHANGED 


HEDLOD# IN FDOSTAT 
ANI HEADLD 


MYI D,HLDLY sTHIS IS THE NUMBER OF 10MS INCREMENTS OF DELAY 
HEDLIs CALL TENMIL 


DCR D 
JNZ HEDL! 
RET 


THIS ROUTINE IS CALLED WITH THE DESIRED SECTOR NUMBER IN SECWNT, AND 

THE DESIRED DISK DRIVE ALREADY ENABLED. THE PROGRAM WAITS FOR THE 
CORRECT SECTOR TO BE UNDER THE READ/WRITE HEAD (THE FIRST SECTOR NOLE 
AFTER THE INDEX HOLE IS THE START OF SECTOR ZERO), AND RETURNS TO THE 
oes PROGRAM ON THE FALLING EDGE (BEGINING) OF THE PROPER SECTOR HOLE. 
STACK 

DATA IN (SECWNT) 

DATA _OUT CHRONOLOGICAL 

A,B,F CHANGED 


SCTGET# IN FDSTAT 
ANI INK 
JNZ SCTGET $WAIT FOT THE INDEX PULSE 
LDA SECWNT $#GET [HE DESIRED SECTOR 
ANI BLOCKS*2-2 


MOV B,A 
SCTLPs IN FUSTAT 
ANI SCTR 
JNZ SCTLP 
DCR B 
RM 
SCTL2s IN FDSTAT 
ANI SCTR 
JZ SCTL2  sWAIT FOR END OF SECTOR PULEE 
JMP SCTLP 


¢ ALL THE PRECEEDING MAY BE ROM 
Peteeete tii ttt iiiitiitttiiete ete P| 
ERRTRARARERAARAARRARERR ARES ERERARERRARE KARR RERRRRRERRARREE RARER AERA 


SALL THE FOLLOWING MUST BE RAM 
$ ALL DATA FILES, LINKED OR CONTIGUOUS, SHALL. HAYE THE FOLLOWING FORMATS 


: BYTE 0-8 FILNAM.EXT, 9 BYTES pee FILE NAME ON EACH BLOCK 
E9 DEVICE NUMBER, IGNOR 

: BYTE 10,11 CURRENT TRACK (3-76), SECTOR (0-305 EVEN) OF .THIS BLOCK 

t] BYTE 12,13 TRACK SECTOR OF PREVIOUS BLOCK (0,0 IF THIS IS FIRST) 

4 BYTE 14,15 TRACK SECTOR OF FOLLOWING BLOCK (0,0 IF THIS IS LAST) 

) BYTE 16,17 BLOCK COUNT OF FILE LENGTH 

t] BYTE 18 RESERVED FOR FUTURE USE 

‘ BYTE 19 BYTE COUNT FOR PARTIALLY FILLED BLOCKS 

i] BYTE 20 BYTE COUNT OF INCOMPLETE DATA BLOCKS 

t] BYTE 21-276 256 DATA BYTES 

‘ BYTE 277 RESERVED FOR FUTURE USE 

] BYTE 278-279 CYCLIC REDUNDANCY CHECK BYTES 

DAYOMs DB i $1-31, DAY OF MONTH IN BCD 
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DOES 1A VMOYR® 
FLGs 


FF ’ 
D9EA ECD9 © \"f- TXTPNT® 


D9EC ODODODOD TXTBUF# 
DA2C 
DA2C 00 VLSTERR® 
DA2D 00 LLSTDSK# 
DAZE DKTRO 
DA2E 
DA36 00 LIENKCNTs 
DA37 0000 SCTNXTs 
DA39 0000 PNTS 
DA3B 00 TRYs 
DA3C 00 
DA3D 00 
DA3E 00 

00 

00 


Anant BB 8 


JAH t¢MSN#YR-1975, LSN@MONTH I-12 
al *NUMBER OF THE VALID DISK DRIVE BIT MAP 


CR.CR,CR,CR SINITIALLZE TO EMPTY 
TX TBUF*+TBFLNG 
te) s#LAST ERROR THAT WAS TYPED 
sNUMBER OF THE LAST DISK TO BE USED 
sUP TO 8 DISKS WITH SEPERATE TRACKS TO KEEP 


sOsLINKED, !*NON-LINKED 

i) sSTEMPORARY POINTER TO NEXT SECTOR 
t+) SPOINTER TQ DIRECTORY CURRENT BLOCK 
oO sCOUNTER FOR 3 ATTEMPTES 

sBUFFERE TO THE FD CONTROLS 
sCURRENT TRACK 

sDESIRED TRACK 


(¢) 
LSTDSK+1 
aaa 


DA3F WNT® DB r) #DESIRED SECTOR NUMBER 
DA40 ISKWNT® DB 0 #DESIRED DISK NUMBER 
DA4! KSINSPT® DS 1 #HOLDS .RETURN INSTR FOR DELETED SIGN ON ROUTINE 
3 $128 BITS OF O SYNC’S THE CLOCK 
DA52 ; $SYNC BYTE GOES HERE’ 
DA53 _- WRFLNMS DS 9 $NAME OF FILE AS IT APPEARS IN THE DIRECTORY 
DASC —-WRDEV# = DS 1 #ONE OF 16 DEVICES OF 16 TYPES 
DA5D — TRKWRTs DS 2 STRACK, SECTOR THAT THIS WILL BE WRITTEN TO 
DA5F “-WRYLNK# DS 2 *TRACK, SECTOR OF THE LAST BLOCK. BEFORE THIS 
DAG! SWFWLNK* DS 2 sTRACK, SECTOR OF THE NEXT BLOCK AFTER .THIS 
| DA63 Ds 4 SRESERVE 4 BYTES FOR EXPANSION 
| DA67 _WRCNT2 DS 1 SREALLY ONLY USED BY THE BYTOT ROUTINES 
| DA6S —WRDAT® DS 256 
| —WRCHKS EQU WRSNCB+LN2SNC 
| DB6B ORG WRCHKS42 
DB6B RBSNEB! DS 1 SHERE FALLS. THE INPUT SYNCBYTE 
DBOC gga? + SOFLNM* DS 9 $SAME AS DIRECTORY ENTRY 
DB75 Evy: DS 1 $s INCONSEQUENTIAL 
DB76 TRKREDs Ds 2 ATHIS MUST AGREE WITH THE TRACK, SECTOR DESIRED 
DB78 YLNKs Ds 2 #LAST TRACK SECTOR READ 
DB7A VRFWLNK# Ds 2 #NEXT TRACK.SECTOR READ FOR THIS FILE 
DB7C Z Ds 4 $EX PANSION 
DB8O VRDCNT® DS i 
x DBS L- (/RDDAT® DS 256 
77 OY pc82 RDCHKS EQU RDSNCB+LN2SNC 
ae \ F pc84 ORG RDCHKS#2 
YG DC84 BITCHKs DS 2 616 BIT CHECKSUM OF NEXT. 148 BYTES 
ran DC86=—sci\) ~+BITMAPs DS 148 82 BYTES/TRACK, 74 TRACKS 
DOIA ss ¢\>\  “REDFIL# DS LN2SNC-1 ¢MONITOR. READ BUFFER AREA 
DE3O0. 24, UMRTFILs DS LN2SNC-1 SMONITOR WRITE BUFFER AREA 
DF46 BCHBUFs DS LN2SNC-1 4BATCH STREAM BUFFER AREA 
EOSC DNEs DS 1 $PEG DOWN THE ACTUAL END ADORESS 
DA4! ORG SINSPT ‘sTHIS AREA IS RELATIVELY UNUSED!! 
DA@! 00000000 SINONs DB 0,0,0,0 
DA45 00000000 DB 0,0,0,0 
DA49 00000000 DB 0,0,0,0 
DA4D 2135DB LXI H, SGNON 
DA5O CD12D4 CALL  TXTYP 
DA53 CD4ED3 —CALL  TXTIN 
gop /veELun DA5S CD20D2 CALL FORBIT 4#GET THE DAY TENS DIGIT 
z Lye eon oan DATERR $NOT A VALID DATE 
/. ~~ MO C,A sSTORE THE UNSHIFTED DATE IN CASE 0 Ci 
Ay ROE Vv 8 87 — ADD rig INLY QNE CHARACTER 
wet DASE 87 ADD A 
fh __— DASF 87 —ADD A 
Kaien DA6O 87 ADD A sSHIFT -4 BITS 
. AGI 47 MOV B,A 
poruLl® DA62 CD20D2 CALL FORBIT ‘sGET THE UNITS DAY DIGIT 
VO ROUT JNC NOERDT sTHIS IS A PROPER DATE, FINISH PROCESSING IT 
separ —-DA68 FEFD cPl ¢—#=0% $THIS IS ZERO IF THE CHAR WAS A ’=* 
DA6A C2EBDA JNZ DATERR sNOPE 
DAGD 79 MOV A,C SRECALL THE DATE? 
DAGE 32E7D9 STA DAYOM sSTORE IT 
DA71 C385DA JMP MCS SAND SKIP PAST THE NEXT SECTION 
DA74 80 NOERDTs ADD B 8A IS BCD DATE 
DA75 E63F ANI 3FH 40 TO 31 
DA77 CAEBDA Jz DATERR 
DA7A 32E7D9 STA DAYOM = $STORE THE DATE : 
DA7D CD3CD3 CALL TI 
DA8O FE2D cPl — 
DA82 C2EBDA JNZ DATERK 
DABS coacDs MC53 CALL TI 
DAu8 4 MOV BA tIST LETTER OF MO s 
DA89 CD3CD3 CALL TJ Sine SS HONEY KPERED 
DA8C 4F MOV C,A 
DA8D CD3CD3 CALL iTiI 
Bist eo Ry ita tStanl8 Wit 
E,12 SSTARTS WITH THE 121 
DA93 211108 XI Hy MONTHS avn 
DA96 7E MC4s) MOV AM 
DA97 23 INX H 


DA98 BS 
DA99 C2ABDA 
DA9C 7E 
DA9YD 23 
DASE B9 
DA9F C2ACDA 
DAA2 7E 
DAAS 23 
DAA4 BA 
DAAS C2ADDA 
DAAS C3B4DA 
DAAB 23 
DAAC 23 
DAAD |D 
DAAE C296DA 
DAB! C3EBDA 


DABé CD3CD3 
DAB7 FE2D 
DAB9 C2EBDA 
DABC CD20D2 
DABF DAEBDA 
DAC2 FEOA 


DAF7-ODDA4 
DAFB~544520 


ARDPR D5CF 
BCHBU DF46 
BLK! DA93 
BLKIN D507 
BYTIN D434 
CHKLO D894 


MCis INX 
MC28 INX 
MC38 OCR 


GTMN§ CALL 


DATERRs Cpl 


i” DATXPL* DB 
6“ 


MONTHS: DB 


SGNONS DB 


DB 


END 


AST UDIEA 
BEGIN LOB2 
BLKI) D50A 
BLKOT DA62 
BYTOT D422 
CHKNA DID7 


MCI SFIRST LETTER DOES NOT MATCH 
MC2 #SECOND LETTER DOES NOT MATCH 


MC3 ¢THIRD LEITER DOES NOT MATCH 
GIMN ALL THREE MATCH 


MC4 
DATERR $NOT.A VALID MONTH 


a #E HAS THE MONTH NUMBER 
DATERR 


BLA tBa2ea 


B tAalO2A 


B tA20-99D 
75 tA IS YEARS BEYOND 1975 
OFH s1975=1991 


E tA HAS YEAR AND MONTH 

MOYR $SO STORE THE PROPER DATE 
A,OC9H $sRETURN INSTRUCTION 

SINSPT #GETS STORED AT THE BEGINING 


7$7=/0% sWAS THE CHARACTER ENTERED A /84? 


¢IF SO, DUNYT DO THE DATE TRIP, SYSGEN 
¢THE USER ENTERED AN INVALID DATE 


H,DATXPL 
TXTYP ‘sHELP HIM GET IT RIGHT 
SINON 


CR, LF,“ DATE FORMAT IS 4-JUL-7%, 7674128 


“pedoyborbephucbutLsunkayheRuanrestsan? 


CR,LF,“K2 FDOS VERSION 1.6 (C) FEB 1977, K WELLES? 


CR,LF,“DATE??,% 74128 


sEND OF FDOS 


AST2 DIFF ASTLP DIFO 
BITCH DC84 BITMA DC86 
BLKI2 Lb46 BLKI3 D55F 
BLOCK 0010 BOUND DI2U 
BYTYP D3EC CHK43 D88E 
CHKSU .D891 CHKWI D808 
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CHKWR D7FC 
CLRLO D7AB 
COMPA D6BA 


CR 

DATER DAEB 
DEL2 D290 
DIRB! D6B0 
DIRIN 0004 
DIRWR DO66E 
DSKLI 0008 
DSKWN DA40 
EOF! D568 
ERDKN 0008 


MEMC! D238 
MODL! DOA7 
MOVLO D4F5 
NODSK D9IC 
NONTR D6OC 
NTYPR D5Al 
NXTLE DOC6 
OPNOT D5A8 
PRIDE 0012 
RDCHK DC62 


REDL! D872 
REDIR DA3B 
RETY2 D3A8 
RNDIN D501 
RR2~DIBI 
RUBON D385 
SCTLP D9D4 
SGNON DB35 
SMAL! D6CA 
SRTRR OOF3 
STEPM FFEF 
TBFLN 0040 
TIt = =D34A 
TRAKM D965 
TRGP D82F 
TRKWR DASD 
TRZLP D90D 
TXTB D354 
TXTPN D9EA 
WCSEL 000) 
WRCNT DAG7 
WRSNC DA52 
WRIGA 0008 
wai = DIO7 


MINI 0000 
MONTH DBI1 
MYNAM D631 
NOGO DI6F 
NTEOF D44E 
NXT9 = D6FI 
NXTSC D6CO 
PNTRD 000) 
RAMND OFFF 
RDDAT DB8! 
RUSNC DB6B 
REDLO D870 
RENAM 0293 
RFWLN DB7A 
RR DI7B 
RRVLN DB78 
SCIGE D9C7 
SCTR 0008 
SINON DA@I 
SMAL3 D6ED 
SRTSW OOF2 
STLOP D863 
TGETL D99C 
TRACK 004D 
TRAKO D959 
TRKRE D0B76 
TRUE FFFF 
TS3  DTI9 
TXTIN D34E 
UNITG D660 
WMB D4EF 
WRDEV DASC 
WRTBU DA42 
WRYLN DASF 
Waa = D157 


CLOSI 


DI5C 


REDFI DDIA 


Beginning on page 149 is acomplete machine readable representation (PAPERBYTE® bar codes) of the 
object code for Ken Welles’ K2FDOS, as assembled in the listing beginning below. This bar code represen- 
tation uses the absolute loader format, in which each bar code frame (one line of bars runnning from top 
to bottom of the page) contains a two byte address followed by data which is loaded in ascending order 
starting at that address. 

; The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 
listing does not correspond directly to the variable length records of the bar codes, but in general use a 
fixed length of 16 data bytes. 


D000 C3 34 DO DB 03 E6 02 CA 03 DO DB 02 E6 7F C9 35 
D010 DB 03 E6 01 CA 3D DO 79 E6 7F D3 02 C9 18 
DOIE DB 03 E6 02 3E 00 C8 2F C9 C4 


D028 F8 DF 1A DD 30 DE E7 D9 EA D9 2C DA C3 B2 DO C3 6D 
D038 03 DO C3 03 DO C3 10 DO C3 10 DO C3 10 DO C3 1E == 33 
D048 DO C3 B2 DO C3 22 D9 C3 BA D2 C3 C3 D2 C3 34 D4 45 
D058 C3 22 D4 C3 07 DS C3 62 D4 C3 9B D4 C3 73 DS C3 51 
D068 A&8 DS C3 Bl D4 C3 CC D2 C3 E3 DS C3 12 D4 C3 3C 49 
D078 D3 C3 4E D3 C3 48 D2 C3 93 D2 C3 35 D2 C3 01 DS IF 
D088 C3 8B DO E3 7E 23 E3 FE IC F2 9F DO ES 6F 87 85 60 
D098 C6 34 6F 26 DO E3 C9 EE 80 FE 05 FO 21 26 DO 23 A6 
DOA8 23 3D F2 A7 DO 7E 23 66 6F C9 31 F8 DF CD 22 D9 D8 
DOB8 CD 41 DA C3 C6 DO OE 2D CD 3D DO CD 4E D3 CD 3C-—s 4D 
DOC8 D3 CA C6 DO 21 BE DO ES F8 FE 52 CA 7B DI FE 53 76 
DOD8 CA F8 DO FE 4A CA ES DO CD C9 D3 10 C9 CD 3C D3 17 
DOE8 FA EO DO C2 ES DO CD OB D2 ES 2A EA D9 2B 7E C9 OF 
DOF8 21 30 DE CD D7 D1 FA 57 DI D2 57 DI CD A8 D5 CD D7 
D108 EA D1 FE 4C CA 20 DI FE 51 CA 6F DI FE 47 CA 5C_ 84 
D118 Dl CD C9 D3 10 C3 07 DI CD 0B D2 EB CD 0B D2 EB_ OF 
D128 7B 95 5F 7A 9C 57 13 OE FF CD C3 D2 4D CD C3 D2 0D 
D138 4C CD C3 D2 4B CD C3 D2 4A CD C3 D2 4E CD C3 D2 —B7 
D148 23 1B 7A B3 C2 44 DI OE FE CD C3 D2 C3 07 DI CD18 
D158 C9 D3 03 C9 OE FD CD C3 D2 CD 0B D2 4D CD C3 D2 2E 
DI68 4C CD C3 D2 C3 74 DI OE FC CD C3 D2 21 30 DECD IE 
DI78 BI D4 C9 21 1A DD CD D7 Di FA C7 D1I DAC7 DI CD AC 
D188 73 DS CD BA D2 FE FF CA Al Di FE FD CACC DI FE 3A 
DI98 FC C8 CD C9 D3 11 C3 B2 DO CD BA D2 6F CD BA D2 A4 
DIA8 67 CD BA D2 5F CD BA D2 57 CD BA D2 77 23 1B 7A_— 57 
DIB8 B3 C2 BI DI CD BA D2 FE FE C2 B2 DO C3 8A DI CD 7B 
DIC8 C9 D3 04 C9 CD BA D2 6F CD BA D2 67 C3 Fi DO CD 42 
DID8 3C D3 F8 C2 D7 D1 CD CC D2 3E 00 3D D8 3C CD E3 1B 
DIE8 D5 C9 OE 2A CD 3D DO CD 4E D3 CD 3C D3 F5 CD 3C—s «78 
DIF8 D3 FA FF DI C2 F6 D1 Fi C9 OE 0D CD 3D DO OE 0A ED 
D208 C3 3D DO 21 00 00 CD 20 D2 D8 29 29 29 29 BS 6F 50 
D218 CD 20 D2 D2 12 D2 B7 C9 CD 3C D3 Dé 30 D8 C6 E9 SE 
D228 D8 C6 06 F2 31 D2 C6 07 D8 C6 0A B7 C9 ES 26 00 99 
D238 7E 2F 77 BE 2F 77 23 CA 38 D2 44 05 3E CO El C9 70 
D248 ES D5 CD E3 DS DA 90 D2 1A F6 80 12 21 09 00 19 ~=60 
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D258 
D268 
D278 
D288 
D298 
D2A8 
D2B8 
D2C8 
D2D8 
D2E8 
D2F8 
D308 
D318 
D328 
D338 
D348 
D358 
D368 
D378 
D388 
D398 
D3A8 
D3B8 
D3C8 
D3D8 
D3E8 
D3F8 
D408 
D418 
D428 
D438 
D448 
D458 
D468 
D478 
D488 
D498 
D4A8 
D4B8 
D4C8 
D4D8 
D4E8 
D4F8 
D508 
D518 
DS28 
D538 
D548 
D558 
D568 
D578 
D588 
D598 
DSA8 
DS5B8 
DS5C8 
DSD8 
DSE8 
DSF8 
D608 
D618 
D628 


56 
DA 
F5 
D3 
D1 
E3 
ES 
El 
ES 
3C 
E7 
FE 
11 
D3 
30 
FE 
FE 
0D 
DO 
95 
57 
D9 
2A 
F5 
DA 
4F 
D4 
C6 
3D 
19 
TE 
37 
SE 
CD 
EB 
23 
c9 
DS 
D4 
63 
0D 
El 
0B 
32 
DS 
DA 
DS 
93 
76 
C9 
DA 
36 
FF 
DS 
FF 
D1 
00 
17 
08 
EC 
D6 
F2 


DS 
CD 
D6 
12 
Cl 
DS 
21 
co 
CD 
D3 
D2 
3A 
09 
717 
D3 
20 
1F 
CA 
3E 
CA 
D3 
95 
EA 
C5 
CD 
D2 
Fl 
07 
DO 
23 
23 
El 
19 
CO 
El 
23 
FS 
El 
21 
DA 
00 
Di 
78 
36 
01 
CD 
El 
5F 
DB 
D3 
Al 
00 
El 
ES 
01 
Cl 
00 
D6 
D6 
DS 
CD 
24 


CD 
12 
EB 
cD 
C9 
D8 
1A 
CS 
3C 
FE 
El 
CA 
00 
CD 
E5 
El 
CA 
B7 
2A 
57 
CD 
CA 
D9 
D5 
EC 
i) 
CD 
4F 
Fl 
71 
B6 
D1 
23 
D6 
ES 
23 
C5 
D1 
00 
E5 
19 
Cl 
Bl 
DA 
03 
12 
ES 
23 
01 
07 
DS 
23 
Di 
CD 
FC 
Fl 
22 
CD 
23 
11 
co 
D6 


6E 
D8 
2A 
58 
ES 
CS 
DD 
DS 
D3 
3A 
E5 
18 
19 
3C 
2A 
C9 
85 
D3 
95 
D3 
01 
57 
36 
TE 
D3 
OE 
00 
CD 
F8 
El 
C2 
C9 
TE 
22 
01 
34 
DS 
Cl 
00 
CD 
71 
Fl 
C2 
CS 
00 
D8 
11 
TE 
OB 
El 
E5 
36 
Cl 
E3 
FF 
B7 
61 
87 
13 
00 
D6 
06 


CD 
2A 
DB 
B7 
EB 
01 
34 
01 
DB 
18 
03 
1D 
3C 
B7 
D9 
D5 
FE 
0A 
B7 
22 
C3 
4E 
21 
ES 
01 
CD 
C9 
DO 
C3 
cc 
D4 
ES 
D1 
DA 
00 
93 
CD 
B7 
61 
D7 
OF 
11 
D4 
ES 
SE 
00 
DB 
B3 
CD 
Cl 
09 
23 
B7 
D2 
36 
CD 
CD 
CA 
C2 
El 
37 
El 


21 
78 
7D 
D1 
CD 
09 
D4 
20 
D2 
D3 
00 
FA 
D3 
El 
TE 
E5 
18 
CA 
D3 
EA 
51 
CD 
EC 
FS 
D2 
3D 
F5 
Fl 
12 
62 
11 
11 
B7 
El 
09 
D4 
60 
C9 
DA 
CD 
OF 
53 
co 
CD 
23 
32 
01 
C2 
F6 
Fl 
00 
23 
c9 
CF 
01 
co 
81 
ie 
F7 
Cl 
DA 
ES 


D7 
DB 
B4 
El 
E3 
00 
El 
09 
FA 
05 
19 
03 
DE 
D1 
FE 
21 
CA 
B7 
23 
D9 
D3 
3D 
D9 
21 
El 
DO 
E6 
co 
D4 
D4 
04 
14 
co 
CD 
4E 
23 
D6 
FS 
3A 
58 
E6 
DA 
F5 
60 
56 
80 
18 
69 
D4 
37 
19 
23 
CD 
DS 
23 
D3 
D7 
D6 
DS 
Fl 
CD 
7TE 


El 
CD 
C2 
c9 
DS 
CD 
c9 
71 
34 
FA 
19 
D3 
30 
Cl 
0D 
EC 
9C 
D3 
C3 
1E 
CD 
DO 
22 
E7 
Di 
Fl 
OF 
TE 
DS 
Di 
00 
00 
F5 
EF 
73 
34 
CD 
C5 
67 
D7 
Co 
01 
3E 
D6 
EB 
DB 
01 
DS 
El 
c9 
SE 
73 
c9 
CD 
36 
03 
c9 
06 
Di 
37 
17 
12 


00 
El 
C3 
ES 
C5 
CD 
30 
C2 
2E 
B9 
D3 
C3 
D3 
c9 
D3 
EA 
12 
D9 
2A 
4F 
21 
A8 
El 
12 
E3 
OF 
FE 
FS 
14 
ES 
C2 
E3 
ES 
37 
72 
D7 
CD 
CD 
01 
ES 
B6 
EB 
0A 
00 
CA 
36 
DS 
01 
Fl 
DS 
El 
01 
C3 
01 
ES 
DS 
ES 
ES 
Fl 
CS 
87 
05 


DS 
88 
D2 
9D 
Cl 
D6 
CD 
D2 
77 
2F 
FA 
D3 
08 
09 
22 
CD 
A2 
4F 
D9 
3D 
D9 
CD 
Cl 
Fl 
45 
OF 
DA 
1F 
19 
0E 
D4 
07 
60 
22 
71 
Di 
D7 
D6 
66 
E3 
CD 
77 
FS 
SE 
D5 
B7 
78 
00 
C9 
CD 
0A 
00 
DS 
00 
D6 
EF 
60 
1A 
c9 
ES 
CA 
31 


D638 
D648 
D658 
D668 
D678 
D688 
D698 
D6A8 
D6B8 
D6C8 
D6D8 
D6E8 
D6F8 
D708 
D718 
D728 
D738 
D748 
D758 
D768 
D778 
D788 
D798 
D7A8 
D7B8 
D7C8 
D7D8 
D7E8 
D7F8 
D808 
D818 
D828 
D838 
D848 
D858 
D868 
D878 
D888 
D898 
D8A8 
D8B8 
D8C8 
D8D8 
D8E8 
D8F8 
D908 
D918 
D928 
D938 
D948 
D958 
D968 
D978 
D988 
D998 
D9A8 
D9B8 
D9C8 
D9D8& 
D9IE8 
DA2C 
DA36 


D6 
E8 
CD 
40 
02 
39 
BO 
12 
37 
OE 
24 
4C 
00 
85 
80 
FE 
21 
96 
FS 
21 
FF 
CD 
D7 
AF 
DA 
D9 
F6 
D3 
32 
1A 
4A 
01 
21 
3A 
1A 
72 
B3 
2A 
47 
6F 
E6 
D2 
4E 
OF 
TE 
CD 
D9 
47 
3C 
D8 
D9 
F3 
75 
DA 
3D 
BO 
E6 
Fl 
C2 
1A 
00 
00 


ES 
D9 
6E 
DA 
02 
DA 
D6 
D8 
C9 
4A 
24 
1E 
D7 
85 
07 
08 
02 
00 
C5 
68 
32 
FC 
CD 
06 
2D 
CD 
0A 
FO 
3C 
BE 
D9 
C9 
76 
40 
01 
D8 
C2 
82 
OF 
78 
E0 
1D 
06 
OF 
32 
4A 
32 
OF 
FE 
C9 
21 
E6 
D9 
TE 
DA 
D9 
20 
E6 
D4 
FF 
00 
00 


2A 
77 
D6 
11 
22 
11 

3A 
21 

7C 
06 
05 
C3 
2F 
C6 
25 
D2 
00 
CD 
DS 
DA 
E9 
D7 
C9 
10 
C8 
B6 
4F 
23 
DA 
CO 
CD 
3E 
DB 
DA 
21 

05 

70 
DC 
OF 
07 
AB 
D9 
00 
32 
3D 
D9 

3D 
OF 
08 
21 

3D 
EF 
B8 
E6 
B8 
CD 
D3 

10 
D9 
EC 


00 


37 
23 
El 
El 
3E 
10 
3F 
81 
92 
10 
C2 
Fl 
A6 
80 
F2 
38 
22 
FS 
ES 
11 
D9 
CA 
D3 
717 
F8 
D9 
CD 
1B 
C9 
13 
2A 
02 
96 
CD 
6B 
C2 
D8 
C3 
OF 
E6 
5F 
21 
09 
3C 
DA 
16 
DA 
OF 
C2 
3D 
DA 
D3 
C2 
FE 
C8 
59 
FS 
C2 
05 
D9 


00 


DA 
36 
DI 
Cl 
DA 
00 
DA 
DB 
Co 
26 
CE 
D6 
717 
SF 
19 
D7 
3E 
D4 
21 
84 
El 
91 
02 
23 
21 
11 
C7 
7A 
CD 
23 
D8 
32 
C8 
C6 
DB 
63 
21 
BA 
OF 
01 
Cl 
2D 
23 
DA 
FE 
6B 
C9 
D3 
28 
DA 
35 
F3 
715 
717 
3A 
D9 
Co 
C7 
F8 
0D 


00 


23 
23 
C9 
6C 
D8 
39 
E6 
DA 
c9 
CD 
0D 
717 
C9 
CE 
D1 
40 
12 
DA 
22 
96 
Fl 
FC 
3A 
AB 
CD 
21 
D3 
ES 
Co 
08 
59 
CD 
D9 
1F 
D3 
C9 
CD 
16 
E6 
57 
0B 
C8 
DA 
DB 
CD 
D9 
D3 
Fl 
CD 
3C 
DA 
D9 
3A 
2C 
47 
D9 
CD 
3F 
E6 
0D 


00 


72 
73 
C5 
DB 
21 
DA 
1E 
TE 
CD 
00 
C2 
El 
DS 
DC 
Co 
DA 
D8 
32 
5D 
00 
C9 
D7 
5C 
D7 
8E 
42 
F3 
D7 
21 
D8 
D9 
48 
21 
D9 
F2 
DB 
8E 
01 
FO 
719 
78 
FS 
717 
Fl 
4A 
15 
08 
E6 
C6 
DA 
E6 
C9 
3E 
F2 
3A 
CD 
71 
DA 
08 


00 


3A 
72 
01 
EF 
DB 
7B 
B4 
B7 
D7 
S 
D6 
Cl 
OF 
7C 
C5 
CA 
81 
D9 
3A 
F6 
06 
37 
CD 
81 
EB 
AF 
FD 
3C 
DB 
F3 
2A 
C2 
DA 
B6 
F3 
DB 
3A 
00 
6F 
OF 
C2 
TE 
F6 
04 
CD 
DB 
3E 
78 
C9 
04 
32 
00 
FE 
D9 
DA 
D9 
15 
1E 
DD 


00 


D9 
AF 
00 
C3 
39 
CD 
32 
CD 
C5 
CA 
C9 
C9 
OF 
E6 
ES 
D7 
11 
D1 
D9 
CD 
C5 
C8 
D8 
5D 
69 
Fl 
F3 
E6 
52 
2A 
C8 
D8 
F8 
CD 
F2 
717 
DA 
TE 
07 
SF 
D8 
08 
Fl 
1D 
D9 
E6 
32 
cc 
C6 
3C 
DA 
AF 
FO 
F6 
CA 
9C 
BF 
DB 
C3 


717 
yh 
09 
81 
DA 
BA 
3F 
C9 
DS 
ED 
D3 
F5 
OF 
07 
3A 
CD 
84 
Cl 
32 
81 
CD 
05 
21 
DA 
DB 
3A 
D3 
F7 
DA 
D8 
CD 
3A 
C3 
C7 
E6 
23 
32 
ES 
E6 
719 
c9 
D2 
717 
D9 
CD 
01 
2D 
43 
D8 
DA 
F6 
0B 
47 
01 
71 
D9 
D9 
Fl 
D4 


DA 
80 
6A 
2A 
8A 
21 
11 
F3 
2C 
88 
DE 
6F 
32 
0B 
83 
2A 
03 
Al 
54 
65 
24 
EC 
SA 
20 
E4 
75 
E9 
9F 
68 
95 
B9 
6A 
C5 
BE 
4A 
E3 
1A 
D7 
9B 
20 
C6 
5F 
B8 
C6 
DA 
FF 
D7 
36 
1F 
C7 
98 
A8 
10 
C2 
3F 
B4 
D1 
Al 
17 
12 
00 
00 
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DA41 
DAS 1 
DA61 
DA71 
DA8 | 
DA9 | 
DAA1 
DABI 
DACI 
DAD1 
DAE 1 
DAF | 
DBO 1 
DBI 1 
DB21 
DB3 1 
DB41 
DBS 1 
DB61 


00 
12 
47 
C3 
2D 
1E 
DA 
C3 
DA 
EB 
83 
CD 
4D 
44 
55 
42 
52 
42 
0D 


00 
D4 
CD 
85 
C2 
0c 
TE 
EB 
FE 
DA 
32 
12 
41 
45 
4C 
4A 
53 
20 
0A 


00 
CD 
20 
DA 
EB 
21 
23 
DA 
OA 
FE 
E8 
D4 
54 
43 
4A 
41 
49 
31 
44 


00 
4E 
D2 
80 
DA 
11 
BA 
CD 
F2 
0A 
D9 
C3 
20 
4E 
55 
4E 
4F 
39 
41 


00 
D3 
D2 
E6 
CD 
DB 
C2 
3C 
EB 
F2 
3E 
41 

49 
4F 
4E 
0D 
4E 
37 

54 


00 
20 
DA 
CA 
D3 
23 
DA 
FE 
87 
DA 
32 
oD 
20 
4F 
41 

4B 
31 

2C 
3F 


00 
DA 
FD 
DA 
CD 
C2 
B4 
C2 
87 
DE 
DA 
44 
34 
54 
41 
20 
36 
4B 


00 
EB 
C2 
32 
3C 
AB 
DA 
EB 
87 
4B 
C9 
41 
2D 
53 
50 


46 


20 
20 


00 
DA 
EB 
E7 
D3 
DA 
23 
DA 
80 
E6 
FE 
54 
4A 
45 
52 
44 
28 
57 


00 
4F 
DA 
D9 
4F 
TE 
23 
CD 
47 
OF 
F4 
45 
55 
50 
4D 
4F 
43 
45 


21 

87 

719 
CD 
CD 
23 
1D 
20 
CD 
87 
C8 
20 
4C 
41 

41 
53 
29 
4c 


35 
87 
32 
3C 
3C 
B9 
C2 
D2 
20 
87 
21 
46 
2D 
55 
52 
20 
20 
4C 


DB 
87 
E7 
D3 
D3 
C2 
96 
DA 
D2 
87 
F7 
4F 
37 
47 
46 
56 
46 
45 


CD 
87 
D9 
FE 
57 
AC 
DA 
EB 
DA 
87 
DA 
52 
B6 
4A 
45 
45 
45 
33 


FE 
9D 
13 
22 
35 
9F 
64 
9A 
DS 
3E 
3F 
CD 
44 
B4 
C3 
B6 
9F 
BD 
14 


AnwWeo 
aAnaN 
AngMw 
An<c< 
anae 
Anewt 
Aaanr- 
anu 
aQato 
annum 
ann 
ancQ 
C-uo 
cC-we 
c-an 
C-Uc 
a-<ca 
ao-a< 
CcC-xr 
Conr~s 
a-so 
a-t+0 
Qa-—moo 
Qa-anw 
Qa--N 
Qonm 
aQcowYU 
acaa 
acuc 
acana 
aook 
AccoYy 
Acros 
QAccr 
acne 
aAcomuU 
Aacns 
acu 
ac-c 
accc 


oma 
Han ome 
omnm 
Wh ome 


omm 


cnt 


URE AUIGNROIRUUIR UUM EID ROR OIIBNIENERIN Com 


ocsx 
|| | oka 
mW oc 
Wi com 


ccn 
cc 
coco 


Quine 
Anwo 
AanVvVU 
AnMBoo 
Qaun<tt 
Aanac 
aQnra 
Anco 
Quunt 
custo 
aun’ 
Owi—oo 
auot 
CrhLo 
et00 
atu 
COwmy, 
aren 
Crock 
crema 
Ow coo 
aAarnn 
artrt— 
aAatng 
ara 
arose 
Anke 
Anau 
fate O1S) 
Anaa 
Anite 
anaan 
OAnnrw 
AamcyU 
Amna 
Aare 
aanan 
aAamnNno 
aAancyu 
Anka 


co~o 
oon 


cows 


overt 
coon 


ocovcn 


ont 
onnm 


omnNn 
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—-—a 


Qokw 
Down 
Qc Ooo 
BoUn 
QBom— 
Coaw 
Bowoowod 
Borne 
Doct 
Qon— 
Com 
Conc 
Qe-c 
Boeocn 
Crakk 
cerco 
crUua 
Cormae 
aonr<n 
Crock 
arco 
Am woo 
QAnrunt 
Arto 
arnYgO 
aro 
Qa~on 
Achn 
acou 
[ja-107--) 
Ocean 
Acct 
Aca 
aocrdO 
acca 
Acnwn 
Cor 
acng 
Qe-< 
acce 


-—-c— 
-coO 


oat 
onam 
oan 
oa 


one 
conn 
oot 
oconom 
onxn 
coo 


one 


Cac-— 
casa 
Aamo 
Qannem 
aAmackh 
Aa<u<c 
aQ<uc 
atone 
e<uc 
A<<aO 
Ac<ac 
A<oom 
A<e~+t 
amcor 
Cmts w 
GQaime 
A<NO 
cCawn 
Cou 
Canyu 
cace 
cqace 
Coase 
Core 
Cawd 
GCoaot< 
aQannr 
Cans 
CGQoa--— 
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APPENDIX I: Data Structures 


This appendix will detail the following data structures: 


File Buffer Area 

Disk Data Block 

Physical Disk Layout 

Directory Organization 

Bit Map Organization 

Run File Format 

FDOS Storage from SYSGEN for Boot 


File Buffer Area 


The organization of the File Buffer Area as it appears anywhere in memory is: 


Byte Usage \ ci AM 
O0to5 6 ASCII character file name ut Ee [ bf ie 
6 to8 3 ASCII character file name extension ee? eee 2 a 
9 Disk drive number Sa Que ta< i Fp 
10,1T Current track, sector N nae SCY 
12,13° Previous track, sector \ REV TH - 

14,15 Next track, sector — eee (=f! ae 

16,17 Block counter within a linked file ‘ha d TY 
Be Reserved for future use BYTES (py 
19 : Byte count of partial blocks ba 
20 Lr Current byte counter Uy! 
21 w276 )34 256 data bytes 7. 
2tt- (35 Reserved for future use | \ y ¥ 
Pass 4 contains a detailed description of the File Buffer Area. )79 


Disk Data Block 


All disk data blocks are stored on the disk as shown below: 


Byte Usage 

-—17 to2 Leading zeroes 

-1 Synchronizing byte (81H) 

0to8 Filnam.Ext 

9 Unused (originally the device number) 
10,11 Track and sector of this block 

12,13 Track and sector of the previous block 
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14,15 Track and sector of the next block rFO 


16,17 Block number of this block within a linked file 
18 Reserved for future use 

19 Byte count of a partially filled block 

20 Unused (originally the byte counter) 

21 to 276 256 data bytes 

277 Reserved for future use 

278,279 Check sum of bytes 0 through 277 

280 to 295 Trailing data 


Pass 4 contains a detailed description of the disk data block. 


Physical Disk Layout 


Different portions of the disk are set aside for different purposes by FDOS. This apportionment is 
detailed below: 


Tracks Sectors Purpose 

(0) All Full track stores one copy of FDOS for BOOT loading 

1 All Full track stores alternate copy of FDOS for BOOT loading 
2 0 Block occupancy bit map 

2 2 to 30 15 directory blocks 

3 to 76 All Linked data files 


Directory Organization 


The directory consists of 15 blocks of 256 data bytes each on track 2, sectors 2 through 30. Each 256 
byte block consists of 16 entries of 16 bytes. The overall directory appears as 240 entries of 16 bytes 
apiece. 


Directory Entry Layout 


Byte Description ‘L-( 
0 If zero, this entry is beyond all valid directory entries 

0 If most significant bit is set, this is a deleted entry 

0to8 9 ASCII characters, Filnam.Ext 

9,10 Track, sector of the first block of this file 

11 2 most significant bits block count overflow (from byte 13) 
11 6 least significant bits Day of Month of creation (1-31 BCD) 
12 4 most significant bits Year of creation (0=1975, F=1991) 
12 4 least significant bits Month of creation (1=JAN, C=DEC) 
13 Number of blocks in the file 

14,15 Reserved for future use 


Pass 8 contains full details on the directory entry. 


Bit Map Organization 


The bit map consists of the first 148 data bytes (bytes 21 through 168 of the disk data block) of the 
block at track two, sector zero. These 148 bytes contain 1184 bits, corresponding to the 1184 blocks 
(1184 = 74 tracks X 16 blocks per track) of data on tracks 3 through 76. 


> 
Byte Description gvi y Loe € 
Ab 
0 Most significant bit=Track 3, Sector 0; Least significant bit=Track 3, Sector 14 
1 Most significant bit=Track 3, Sector 16; Least significant bit=Track 3, Sector 30 
2 Most significant bit=Track 4, Sector 0; Least significant bit=Track 4, Sector 14 
147 Most significant bit=Track 76, Sector 16; Least significant bit=Track 76, Sector 30 


In any byte of the bit map, if a bit is set (one) then the block that this bit corresponds to (according to 
the preceding table) is part of a linked disk data file. If a bit is cleared (zero) then the corresponding 
block is not part of any file at this time, and is available for incorporation into a file. 


Run File Format 


For a file to load correctly in response to an FDOS RUN command, it must be in the proper RUN 
format, as shown below. This is the format of data in the file created by the SAVE command. Run format 
files are composed of a set of one or more memory images (copies of data from memory) followed by 
either one start command or one return to FDOS command. 


Memory Image of N Bytes 


Byte Value 

1 EF 255 

2 Low byte of the start address of the following data 
3 High byte of the start address 

4 Low byte of the byte count of the data to follow 
5 High byte of the byte count 

6...N+5 N data bytes as they appear in memory 

N+6 FE 254 

Start Command 

Byte Value 

1 ‘ ) 253 

2 Low byte of the start address 

3 High byte of the start address 


Return to FDOS Command 
Byte Value 


1 252% 


FDOS Storage for BOOT from SYSGEN 


The SYSGEN program stores a copy of the first 3584 bytes of FDOS on track 0 or track 1. This data is 
stored as one large block of data, starting at the index pulse (not the sector pulse) to speed the BOOT load 
procedure. The block begins immediately after the disk index pulse and has the following format: 


Byte Contents 

—17 to —2 Leading zeroes ee 

- hronizing byte ; ; 

0 H ne high seh of the address of the data to follow and the start address if the load is successful 
23 Low, high byte of the number of bytes to follow 

4 to 3587 Data (a copy of FDOS) 

3588 3589 Low, high byte of 16 bit sum of bytes 4 to 3587 

3590 to 3605 Trailing zeroes 


This format is not restricted to a 3584 byte record loaded into memory starting at DOOOH. ope 
from 1 to approximately 5000 bytes can be loaded into any desired location in memory using this format 


and the BOOT program listed in Appendix F. 


APPENDIX J: FDOS Error Codes 


Code Meaning 

01 Read error 

02 Write error 

03 Duplicate file exists 

04 No such file exists 

05 The directory is full 

06 The disk is full 

07 Read beyond end of file or unclosed file being read 
08 No such disk exists 

09 Illegal file name typed in 

10 No such FDOS command exists 

11 The file is not in the proper format to run 
12 An unclosed file has been deleted 


Explanations, Possible Causes, and Remedies 


READ ERROR (01) 


A read error occurred while trying to read a block of data. You may be reading from an unformatted 
disk, or this block may have been physically damaged or partially erased. Possibly the disk drive is out of 
alignment. If this happens on only one part of the disk, suspect damage. Get a new disk and save as much 
of the data from the damaged disk as possible. If the disk is just unformatted, then format it and continue. 


WRITE ERROR (02) 


A write error occurred while trying to write a block of data. Usually this means that the disk is write 
protected. If the disk is write protected, remove the write protection and start over. If the disk is damaged, 
replace it with a new, formatted disk. An unformatted disk will not cause this error. 


A DUPLICATE FILE EXISTS (03) 


An attempt has been made to opena file for output, but another file by this name already exists. If you 
were trying to SAVE a program, then choose another name and try again. In any other case, delete the 
existing file, change the name of the existing file, or change the name of the file to be written. Next time, 
use the LOKFIL routine to assure the file does not exist before trying to open it for output. 


NO SUCH FILE EXISTS (04) 


An attempt was made to open a file for input, but the file does not exist. Check to see that you have 
not misspelled the name, specified the wrong drive, or have the wrong disk mounted. If none of these are 
true, then you must first create the file that you are attempting to read. In the future, program the 
LOKFIL routine to check that a file does exist before you try to read it. 
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THE DIRECTORY IS FULL (05) 


The directory has already got 240 different file names (112 names on a 5 inch floppy drive) entered 
in it. Before you can create (open for output) any more files you must either get a new disk or get rid of 
some files via the DELETE routine in FDOS or the DELETE function in PIP. If possible, send the output 


to a different disk drive. 
THE DISK IS FULL (06) 


While writing data out, the entire disk filled up on you. This is unfortunate, since there is almost no way 
to retrieve all of the data that you were writing. Your best bet is to start over with a new (or at least less 


full) disk. 


READ BEYOND END OF FILE (07) 
You were reading data in from a disk file and one of two things happened: 


1) You have tried to read more data than there is in the file. All data coming in to you at this time is 
meaningless. Next time check for the end of file conditions in your program (carry bit set on FDREAD 
or BYTIN, zero forward link on BLKIN). 

2) The file that you are reading either was not closed when it was created, or this file has been corrupted 
by careless use of the RNDOT routine. The data beyond the bad link is lost. Try to reconstruct the 
file however possible. 


NO SUCH DISK EXISTS (08) 


You have requested disk operations (read or write) on a nonexistent disk. This may be a drive without a 
disk inserted, or a disk drive door that has been left open. Also check that you did not specify a file like 
ABLE:2 when you have only two drives (the drives are numbered 0 and 1). 


ILLEGAL FILE NAME TYPED IN (09) 


The FILNAM routine could not convert the TXTIN buffer contents into a legal file name. Check to see 
that you typed the desired file name in correctly. Review Pass 5, the section on FILNAM. 


NO SUCH FDOS COMMAND EXISTS (10) 


FDOS only accepts the RUN, JUMP, or SAVE commands. Make sure that your command was entered 
as Pass 1 or Pass 2 describes. 


THIS FILE IS NOT IN THE PROPER FORMAT TO RUN (11) 


You have tried to RUN a file that is not in the proper format for an executable file. Usually this 
indicates that you typed in RUN ABLE when you meant RUN ABLE.BIN or ABLE. OBJ. Use the PIP 
ee command to check for the correct name. Check Appendix | for the proper RUN format 
or a disk file. 


AN UNCLOSED FILE HAS BEEN DELETED (12) 


During a DELETE operation, the file being deleted was either never closed when created, or the file 
has been corrupted by the RNDOT routine or by disk damage. ERROR 12 is a warning that the file being 
deleted is no longer a properly linked file. FDOS will delete as much of the file as is properly linked, and 
ignore the rest of the file. 
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APPENDIX K: Hardware 


The software in this book was written to be used with a simple, low cost floppy disk interface. This 
interface was first published in the February 1977 issue of BYTE magazine and is reprinted in this appendix 
for the reader. Since the original printing of the article, four integrated circuits have been added to the 
design of the interface. These additions increase the drive capacity of the interface, making it more reliable 
and universally compatible with the various S-100 bus computers now available. The theory of operation 
has not changed. Those hobbyists who do not wish to build the circuit from scratch can purchase hardware 
that is fully software compatible from: 


Ithaca Audio 
PO Box 91 
Ithaca, NY 14850 


Those who wish to adapt FDOS to their existing hardware are referred to Appendix L. 


159 


Build This Economy 


Floppy Disk Interface 


The floppy disk drive offers the advanced 
computer hobbyist tremendous potential fora 
high performance computer system. With 
one or more floppy disk drives, an interface, 
and the proper operating software, the 
hobbyist can store hundreds of different 
programs on a single disk. Each of the 
programs can be given a name such as 
STARTREK, BASIC or EDIT, and a pro- 
gram can be run simply by typing its name, 
for instance ‘RUN EDIT”. With this inter- 
face, the program can be brought into the 
computer at speeds of up to 31,250 bytes 
per second (for programs less than 5000 
bytes long in the proper format). Each disk 
will store over 300,000 bytes of programs, 
computer music, Dazzler graphics, ASCII 
text, synthesized speech thesaurus or data of 
any form, and any data on the disk can be 
accessed in at most one second, typically in 
less than one quarter second. In fact, the 
draft of this article was written and edited 
using mass storage on a disk drive in my 
personal home computer system. The entire 
article takes up less than seven percent of 
one floppy disk, and the time saved in the 
retyping of successive revisions of the article 
was tremendous. /Groan! Do | wish | had a 
floppy disk, CRT display, HYPERTEXT 
software and input scanners in my office... 
CH] 

Floppy disks also allow the quick assem- 
bly of large programs, without having to 
start, stop and rewind cassette players. 
Proper software allows a single floppy disk 
drive to merge several data files into one 
ordered file (for the updating of mailing lists 
or financial records), an operation which 
would take several cassette recorders on a 
cassette based operating system. 

All of the features mentioned are the 
potentials of a floppy disk computer system. 
For a personal computing user to realize 


these potentials, he or she needs both 
hardware and software. This article covers a 
hardware interface for floppy disk drive 
units. 

Until recently, only the well financed 
hobbyist could afford a floppy disk drive for 
a personal system. In addition to the $650 
to $1000 cost of the drive unit, one was also 
forced to spend from $300 to $1500 for a 
floppy disk drive controller. The high price 
of the controller buys a very intelligent 
electronic device, however. A single com- 
mand from the computer causes the con- 
troller to seek a particular track on one of 
up to four disk drive units, load the head, 
find the desired sector, format and read or 
write the data, calculate the CRC (Cyclic 
Redundancy Check), determine if the trans- 
fer had been successful, and retry the trans- 
fer in the event of aread or write error. The 
design of such an intelligent controller is 
based on the old school, IBM/360 approach 
that processor time is too valuable to waste 
doing the housekeeping for a peripheral 
device. A personal computing user, on the 
other hand, has lots of processor time, 
limited funds, and consequently a different 
philosophy. One of the original reasons for 
the development of microprocessors was to 
perform in software all of those functions 
that would normally (and expensively) have 
to be designed in hardware. In this vein, in 
collaboration with W R_  Hemsath of 
Cornell University, | have designed and built 
a floppy disk drive interface which incor- 
porates minimal hardware, and yet does not 
sacrifice the flexibility needed to read and 
write various data formats. This interface 
consists of only 17 integrated circuits, only 
one of which is a special purpose chip. The 
total cost of the chips is less than $25. The 
design shown here will interface up to eight 
floppy disk drives to an 8080 processor. In 
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This diagram, The signals sent to the drive from the interface 

Device Select: When this line is high, all 
commands from the interface are ignored by the 
drive, and all signals from this drive unit are put 
into a high impedance state. If several drives are 
used, all of the input and output signals may be 
tied together on acommon bus with the exception 
of the device select lines. By pulling only one of 
the several device select lines low, the interface 
selects that particular disk drive to send commands 
to and receive data from. 

Step: A low going pulse on this line causes the 
head positioning motor to move the data transfer 
head in or out one track. 

Direction: During a step pulse, if this line is 
high then the head moves out one track (towards 


Series 200-M Maintenance 
Manual, shows all of the 
TTL level signal lines that 
must be passed between 
the disk drive and the con- 
trolling interface. 


track 0). If this line is low, then the head will move 
in one track. 

Head Load: When this line is low, the pressure 
pad brings the spinning disk in contact with the 
data transfer head. 

Write Current Select: Because the surface veloc- 
ity of the disk relative to the head varies from the 
outermost to the innermost track, the density of 
the data on the disk will also vary. To compensate 
for this variation, the write current select line 
varies the amount of current used to write data as a 
function of the track being written. This line must 
be low when writing data onto tracks 0 to 43, and 
high for tracks 44 to 76. 

Write Gate: Pulling this line low enables the 
data on the write data line to be sent to the head 
and recorded onto the disk. 

Write Data: Data to be written on the disk must 
be serialized and sent out on the write data line as 
a series of low going clock pulses (one pulse every 
4 us) separating the presence (a 1 data bit) or 
absence (a O data bit) of a low going data pulse. 
Figure 2 shows the write data signal used to send 
the data bit string 10100. 

File Unsafe Reset: This line is pulsed low just 
before a write operation is to take place. The pulse 
resets the file unsafe status to a safe (write 
enabled) condition, thereby allowing the write 
operation to be performed. 


The signals sent to the interface by the disk 
drive are: 

File Unsafe: A low signal on this line indicates 
that an error condition existed when a write 
operation was attempted. When file unsafe goes 
low, no writing can be done on the disk, preventing 
the loss of previously written data due to some 
error condition. 

Track Zero: When the data transfer head is 
positioned at track 0, this line goes low, enabling 
the computer to calibrate the head position. When 
the head is at tracks 1 to 76, this line is high. 

Index: A 500 us low going pulse appears on this 
line to signify that the index hole has just come 
into position under the photodetector. This pulse 
is used by the computer to determine which sector 
is sector 0. 

Sector: A 500 us low going pulse appears on 
this line each time a sector hole (not an index hole) 
Passes under the photodetector. 32 pulses occur 
every revolution, and these pulses are used to 
determine the approximate starting positions of 
the various data sectors. 

Ready: When AC and logic power are present at 
the disk drive and a disk is loaded, the ready line 
goes low. 

Separated Clock: When previously written data 
is being read from the disk, the clock is recovered 
from the data stream, and is presented on this line 
as a series of 200 ns low going pulses. The 
recovered clock pulses come approximately every 
4 us with variations due to the changes in drive 
motor speed. 

Separated Data: The serial data coming from 
the disk during a read is indicated by the presence 
(a 1 data bit) or absence (a 0 data bit) of a 200 ns 
low going pulse on the separated data line, between 
adjacent separated clock pulses. 

Write Protect is an optional signal that is not 
used in this interface. On a disk drive with this 
option added, the user can write protect the data 
on a disk by punching out or uncovering a write 
Protect hole in the disk jacket. A write protected 
disk cannot be written onto. 


order to properly describe the design and 
function of the interface, let us first review 
briefly what steps are required to transfer 
data to or from a floppy disk. 


Disk Drive Operation 


In operation, a disk is inserted into the 
drive and the access door is closed. The act 
of closing the door engages the disk onto the 
spindle, and the disk is then rotated at 360 
RPM. A stepper motor drives the magnetic 
data transfer head radially in and out to 77 
discrete positions, the outermost called track 
0 and the one nearest the center of the disk 
called track 76. Normally, the head does not 
touch the spinning disk, but is positioned a 
small distance away from it. When data is to 
be read or written, a modified relay is 
energized allowing a spring loaded pressure 
pad to press the flexible disk into contact 
with the head. Timing holes punched in the 
floppy disk pass by a photo detector and 
generate a series of pulses. These ‘“‘sector 
pulses” are used to determine which one of 
32 segments or sectors of the disk is cur- 
rently passing the head. Use of such holes to 
define sectors is called “hard sectoring” in 
disk drive jargon. The pulses are used to 
signal the approximate starting point of each 
sector. Data is read from and written to the 
disk in a manner quite similar to the reading 
and writing of data on magnetic cassettes. In 
normal operation, each of these 32 sectors 
will store slightly over 1024 data bits, or 128 
bytes. To write data onto a particular track 
and sector of the disk, the following opera- 
tions must take place: 


1. The head is moved in or out to the 
desired track. 

2. The pressure pad is loaded, pressing 
the disk against the head. 


3. Sufficient settling time is allowed for 
the head movement and pressure pad 
loading to fully stabilize. 

4. Delay until the start of the sector 
pulse which corresponds to the desired 
sector. 

5. Turn on the WRITE GATE of the disk 
drive to allow data to be written. 

6. Write 64 0 bits (16 bytes of 0). 

7. Write a single synchronizing byte (sync 
byte). 

8. Write the desired data bytes. 

9. Write 64 0 bits. 

10. Turn off the WRITE GATE to prevent 
any more data from being written. 

11. Unload the pressure pad. 


Because the disk drive records data seri- 
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Figure 2: The timing of data cells on the disk. Each bit cell is framed bya 
clock pulse on either side. If the data is 1, a pulse appears in the middle of the 
4 us cell width; if the data is 0, no pulse appears in the middle of the cell. The 
waveform in this example has 5 cells with the pattern of data needed for the 
string 10100. 


ally, steps 7 and 8 require that each byte 
being written must be sent out as a series of 
8 bits, with one bit being sent out every 
4 us, and with no skipped bits between bytes. 

Reading data from the disk requires a 
similar series of operations: 


1. The head is moved to the desired 
track. 

2. The pressure pad is loaded. 

3. Settling time is allowed for movement 
and loading. 

4. Wait for the start of the sector pulse 
corresponding to the desired sector. 

5. Search for the first occurrence of the 
sync byte. 

6. Read in the desired data. 

7. Unload the pressure pad. 


Searching for the sync byte entails shift- 
ing the incoming serial data into an 8 bit byte 
and comparing the result of each shift with 
what the sync byte should be, every time 
that a new bit is read (every 4 us). When a 
match is found, then the data bit stream that 
follows is broken into bytes on every eighth 
bit, using the sync byte boundary to define 
the data byte boundaries that come after the 
sync byte. 

From the preceding lists of read and 
write procedures, two things become appar- 
ent: First, the speed required for shifting 
data in and out (1 bit every 4 us) is too fast 
for most microprocessors to handle under 
software control (and searching for the sync 
byte is more time consuming still!) Second, 
all of the other operations (stepping the 
head from track to track, loading the head, 
searching for the proper sector pulse and 
turning the write gate on and off) are easily 
within the capabilities of microprocessor 
software control. Therefore a minimum 
hardware interface should control all of the 
functions which are not time-critical, 
through software and a simple input and 
latched output port. The remaining func- 
tions then determine the major portion of 
the design. 
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| Figure 4: This diagram shows the circuitry used to perform all of the low speed functions of the disk drive. IC8 is a 6 bit input 


port, and IC5 and 1C6 are an 8 bit latched output por I 
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r , , , ae " rv p to 8 disk drives on the system, and IC9 controls the 
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Table 1: Semantics of the OUT 243 instruction. This table lists each 
accumulator bit, along with its meaning when used to transfer data to the 
disk interface in the OUT 243 instruction of an 8080. (In a different wiring 
of the 1O instruction decoder, or in a different computer, the same format 
could be used for the actual data transfer.) 


OUT 243 INSTRUCTION 

Bit Signal Name Polarity in Accumulator 

0 Write Current Select 1 for tracks 0 to 43, O for track 44 to 76 

1 File Unsafe Reset 0 to 1 to O transition causes reset 

2 Direction 1 for step in, O for step out 

3 Write Gate 1 enables the drive to write 

4 Step Track 0 to 1 to O transition steps one track 
5,6,7 Drive Select 000 selects drive 0, 111 for drive 7 


Table 2: Semantics of the IN 241 instruction. This table lists the status bits 
read by the IN 241 instruction of an 8080 using this interface. 


IN 241 INSTRUCTION 


Bit Signal Name Polarity in Accumulator 
0 Track Zero O means the head is at track 0 
1 File Unsafe O means file unsafe condition exists 
2 Ready O means disk drive is ready 
3 Sector Hole 1 to 0 transition marks start of each sector 
4 Index Hole O means that the next sector is sector 0 
5 Head Loaded 1 means that the head is still loaded 
6,7 Unused Always 1 
Table 3: Integrated cir- | Number Type +5V GND 
cuit power wiring list. 1c1 741.30 14 7 
This table lists each in- 1C2 74L42 16 8 
ircuit ji IC3 74L30 14 7 
mais hg - the +5 bet i ui 
ppy disR intertace, IC5 74LS175 16 8 
along with its power | Ss 74LS175 16 8 
iri ‘ 1C7 7442 16 8 
WEE EES: 1C8 8097 16 8 
Ico 74123 16 8 
1C10 74123 16 8 
1C11 74193 16 8 
1C12 7442 16 8 
1C13 74123 16 8 
1C14 7438 14 7 
1C15 7400 14 7 
1C16 74L04 14 7 
1C17 $2350 2 1 


Note: 74LXX and 74LSXX types may be replaced 
by 74XX; 8097 may be replaced by 8197. 


The disk drive we used for this interface 
is an Innovex 220 hard sectored flexible disk 
drive, and the signal lines required to operate 
the drive are typical of most floppy disk 
drives. There are 15 standard TTL level 
signals required to operate the model 220 
drive, 8 from the interface to the drive, and 
7 from the drive to the interface. The signal 
names and functions for the interface are 
summarized in figure 1. 

Figures 3 and 4 show the circuitry of the 
floppy disk interface. The circuit has 6 
major sections: processor IO instruction 
decode, instruction latch to disk drive, status 
load from disk drive, head load-unload, 
USRT transmit, and USRT receive. 


Processor 10 Instruction Decode 


IC1 and IC2 decode output instructions 
to the interface. Executing the 8080 instruc- 
tions OUT 240, OUT 241, ... OUT 247 
(240 to 247 decimal) cause 500 ns low 
pulses on the output lines 0 to 7 of IC2. 
These pulses can be used to latch data from 
the output data bus lines DOO to DO7 into 
various registers, or to trigger specific func- 
tions (as will be shown later). 

IC3 and IC4 form the input instruction 
decoder for the instructions IN 240 to IN 
247 in a similar manner to the output 
decoder. The pulses on the output lines of 
1C4 are used to gate data onto the input data 
bus lines DIO to DI7 and into the accumula- 
tor. Again, the pulses may be used to trigger 
specific functions that are not data input 
operations. //n adapting this design to anon 
8080 based computer, this decoding logic 
would have to be modified.... CH] 


Instruction Latch to Disk Drive 


Execution of an OUT 243 causes the 
contents of the 8080’s accumulator to be 
loaded into ICS and IC6. The 5 least 
significant bits are used to send the low 
speed control signals to the disk drive. Table 
1 shows the allocation and the polarity of 
these bits as they appear in the accumulator. 
The three most significant bits are used by 
IC7 to select one of up to eight different 
drives which may be attached to each 
interface. 


Status Load from Disk Drive 


Execution of an IN 241 instruction en- 
ables IC8 to load the current status of the 
selected disk drive onto processor input data 
lines DIO to D15. Table 2 shows the alloca- 
tion and polarity of these bits as they are 
loaded in the accumulator. The two most 
significant bits are unused, and will always 
show 1s. 


Head Load-Unload 


IC9 is a retriggerable one shot with a 2 
second pulse width. Executing an OUT 245 
instruction initiates this pulse and loads the 
disk drive head, regardless of the contents of 
the accumulator. If another OUT 245 in- 
struction is executed within 2 seconds of the 
first OUT 245, then the head will remain 
loaded for a further 2 seconds. The head will 
unload 2 seconds after the last OUT 245 


(load head) instruction. This 2 second 
pause allows the head to stay loaded during 
successive reads and writes to the disk, but 
will automatically unload the head after 2 
seconds without any disk activity. Alter- 


natively, an OUT 246 instruction will cause 
the head to be unloaded immediately if and 
when that is desired. This automatic head 
unload feature minimizes wear on the floppy 
disk. If it were not present in some hardware 
or software form, the head would be con- 
tinuously in contact, wearing out disks quite 
quickly if your machine ran 24 hours a day. 


The USRT 

The abbreviation USRT stands for Uni- 
versal Synchronous Receiver Transmitter; 
this chip really is quite universal. Although it 
was originally developed for data trans- 
mission over phone link, wire link, and some 
types of tape drive, the $2350 USRT per- 
forms all of the needed high speed data 
transfers to and from the disk with almost 
no modification. Before discussing the 
operation of the USRT transmit and receive 
sections of the interface as a whole, take a 
look at the functions of the USRT itself, as 
denoted by the various signal lines. Figure 5 
shows a block diagram of the $2350, along 
with captions detailing these lines and their 
relation to the interface as a whole. 


USRT Transmit 


After the disk drive head has been loaded 
and the desired track and sector found, the 
write gate is turned on and data from the 
processor may be sent to the transmit 
section of the USRT through an OUT 240 
instruction. IC11 divides the Altair 2 MHz 
clock by 8 to give the 250 kHz clock 
required by the disk drive. This clock is fed 
into TCP, and 1C12 combines the data from 
the transmitter serial output line and an- 
other clock phase into the proper write data 
format required by the disk drive as seen in 
figure 2. 


USRT Receive 


1C10 is simply used as a pulse stretcher 
for the separated data and separated clock 
from the disk drive. The data pulse is 
expanded to overlap the falling edge of the 
clock pulse. This overlap allows the data to 
be read properly by the USRT. When a byte 
of data has been received (as denoted by the 
receiver data available linc), an IN 240 in- 
struction will load the received data into the 
accumulator. 


Software Timing 


The article to this point has shown how 
data can be transferred between the proc- 
essor and the disk drive in the correct 
format, but nothing has been said about the 
ability of the 8080 to send or receive data at 


the proper rate. A 250 kHz bit rate is one 
byte of data in or out every 32 us under 
ideal conditions. If the drive motor speed 
variations are taken into account, this figure 
can be as low as 30us per byte on a read 
operation. Since 8080 instructions take from 
2 to 7us to execute (assuming a 2 MHz 
clock and fast memory), this restricts the 
read loop to very few instructions. If it is 
desired to transfer more than 256 bytes in or 
Out at any one time, the read loop might 
look like: 


Symbolic Execution 
Instruction Time 
LOOPA: IN STATUS 5.0 us 
ANI DATAREADY 3.5 Us 
JZ LOOPA 5.0 us 
IN DATA 5.0 us 
MOV M,A 3.5 us 
INX H 2.5 Us 
DCX B 2.5 Us 
MOV A,B 2.5 US 
ORA C 2.0 us 
JNZ LOOPA 5.0 us 
36.5 us 


In the above example the HL register is 
used to point to the data buffer, and the BC 
register is the number of bytes to be read. 
The total time of the loop, 36.5 us, is 6.5 ws 
too long for the worst case data read. 
Obviously this program will not read data in 
properly. 

By eliminating two lines of code the loop 
is reduced to a total time of 28 us as shown 
in the following example. This is quite ample 
for the interface and allows additional lee- 
way for the possibility of dynamic memory’s 
introducing a wait state during the loop. 


Symbolic Execution 

Instruction Time 
LOOPB: IN DATAWAIT 
(IN 244) 5.0 us 
IN DATA 

(IN 240) 5.0 us 
MOV M,A 3.5 us 
INX H 2.5 Us 
DCX B 2.5 US 
MOV A,B 2.5 Us 
ORAC 2.0 us 
JNZ LOOPB 5.0 us 
28.0 us 


Obviously this version of the routine will 
not work without some special “trick.” In 
this case, the trick is that the first three lines 
of LOOPA have been replaced with the first 
line of LOOPB and some special hardware. 
The first three lines of LOOPA prevented 
the IN DATA statement from reading data 
before data was available. In LOOPB, the IN 
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DATAWAIT is an IN 244 instruction. This 
triggers 1C13b, a one shot, which puts the 
8080 into a slow memory wait state by 
pulling the Altair’s PRDY line low. When 
data is ready for input, the RDA line of the 


USRT resets 1C13b and allows the LOOPB 
routine to continue. During normal execu- 
tion of a read operation, the 8080 does a 
4 us wait between lines 1 and 2 of LOOPB. 
This wait state serves to synchronize the 


Figure 5: This is a block diagram of the USRT inte- NDBI 
grated circuit, the AMI 52350. The information here NDB2 
is redrawn from the original contained in AMI’s data POE 
sheet on the device. The USRT integrated circuit is wee 
the heart of this inexpensive floppy disk interface, 
performing all of the high speed data manipulations 


needed to read and write data from and to the disk TCP a 
drive. The USRT was not intended to be used asa am 3 
floppy disk interface when it was originally designed. eer =| 


But as demonstrated by this article, a little ingenuity 
can often come up with surprisingly versatile applica- 
tions of standard integrated circuits for use in high 
speed data communications. 
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TDS Transmit Data Strobe 


An OUT 240 instruction of this interface puts a 
pulse on the TDS line which loads the accumulator 
into the USRT transmitter buffer through proc- 
essor data output lines TDO to TD7. The USRT 
then shifts this data byte out onto TSO (Transmit 
Serial Out). One bit is shifted onto TSO for each 
pulse on TCP (Transmit Clock Pulse). 


TBMT Transmit Buffer Empty 


Whenever the transmitter buffer is ready to 
receive another byte (from an OUT 240 instruc- 
tion), the TBMT line goes high. 


TFS Transmit Fill Strobe 


An OUT 241 puts a pulse on the TFS line 
which loads the accumulator into the USRT fill 
buffer. If new data is not sent to the transmit data 
buffer by an OUT 240 soon after a TBMT signal, 
then the USRT has no data to send out on the TSO 
line. In this case, data from the transmit fill buffer 
is sent out in place of the missing data. 


RSS Receiver Sync Byte Strobe 


An OUT 242 pulses the RSS line which loads 
the accumulator into the USRT sync byte buffer, 


34 —— 
RECEIVER OUTPUT REGISTER 135 SWE 
OUTPUT TRI-STATE DRIVERS RDE 


RD7 RD6 RDS RD4 RD3 RD2 RDI RDO 
TBMT FCT SCR RPE RCR RDA 


for use at the beginning of a data read operation. 


RR Receiver Reset 


An IN 243 causes the receiver section of the 
USRT to be reset into the ‘'Search for Sync Byte” 
mode. The received serial data stream enters on 
RSI (Receive Serial Input), and is clocked into the 
received data buffer by the RCP (Receive Clock 
Pulse) line. When the data byte in the received data 
buffer matches the byte in the sync byte buffer, 
the RDA (Received Data Available) line goes high. 
After this happens, a new byte is put into the 
received data buffer after every eight clock pulses 
on RCP. 


RDE Received Data Enable 


An IN 240 instruction pulses the RDE line. 
This puts the data in the USRT received data 
buffer onto data lines RDO to RD7, and it is 
loaded into the accumulator. In this manner, the 
8080 brings in the data read from the disk. 


SWE Status Word Enable 


An IN 242 pulses the SWE line which loads the 
USRT status word into the accumulator to ex- 
amine for data ready, or to find possible errors. 


reading of the disk data with its availability. 
Any amount of data from a partial segment 
to an entire track may be input with this 
routine, 

If some hardware failure should occur, 
and data stops coming into the USRT, then 
RDA will never go high. If no data arrives 
after 3ms, then I1C13b completes the one 
shot cycle and releases the 8080 wait state. 
This feature prevents a hardware failure in 
the disk drive or interface from hanging the 
processor up in an endless wait state. 
Whether a read operation is successful or 
not, the end of the loop is reached when the 
BC register pair’s count is decremented to 
zero and the JNZ condition no longer 
pertains. 

In order to write data, a software output 
loop similar to LOOPB is employed: 


Symbolic Execution 

Instruction Time 
LOOPC: OUT DATAWAIT 
(OUT 244) 5.0 us 
MOV A,M 3.5 us 
OUT DATA 

(OUT 240) 5.0 us 
INX H 2.5 us 
DCX B 2.5 Us 
MOV A,B 2.5 Us 
ORAC 2.0 us 
JNZ LOOPC 5.0 us 
28.0 us 


With this output loop, the 8080 can 
maintain the data rate required to transmit 
data to the disk properly. A similar hardware 
synchronization trick is also used in this 
case. 


Final Hardware Notes 


The circuit shown in figures 3 and 4 was 
developed for use with an Innovex 220 
drive. The 220 has multiple options which 
can be selected by jumpers on the circuit 
board. The options required for use with this 
interface are: 

1. Radial Interrupt Disabled (Link E 

installed) 


2. Radial Rotation Sensing Disabled 
(Two Link Es installed) 

3. Read Data Option Disabled (Link A 

installed) 

4. Write Protect Option Disabled (Link H 

installed) 

5. Stepper Power Option (Link E 

installed) 

6. Radial Head Load Disabled (Link E 

installed) 

The selected options allow multiple drives 
to be used with the interface. While up to 
eight disk drives can be connected in parallel 
(with the exception of the device select 
lines), the shorting clip on the PO7 line must 
be removed from all but the last disk drive 
on the bus (P07 connects the bus termina- 
tion resistors to +5 V). In addition, the user 
must provide power supplies for the follow- 
ing voltages and currents: 

+5 V, 800 mA for each drive 

—5 V, 75 mA for each drive 

+24 V +/—2 V, 1.4A for the first drive, 

0.1 A more for each additional drive 


Conclusion 


The small number of ICs in this circuit 
(17) and their low cost and easy availability 
puts the construction of this circuit within 
the abilities of many intermediate and ad- 
vanced computer hobbyists and experi- 
menters. The addition of a disk drive to the 
average home system will increase the overall 
system usefulness many times. By reducing 
the time required for software generation to 
a fraction of that on a cassette or paper tape 
system, software throughput and sophistica- 
tion of the typical personal computing user 
(and professional) will typically double or 
triple. 

| currently have two drives running on 
an Altair system, and a complete disk 
operating system existing in 2 K of PROM 
that allows operating with up to 240 
different named files on each disk. Loading 
BASIC takes only 6 seconds, and loading 
STARTREK using CLOAD takes only 3 
more seconds. The disk drive and operating 
system has increased software generation at 
least fourfold, and made the system much 
more enjoyable to use.@ 
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APPENDIX L: 


Interfacing to Other Disk Interfaces 


It is quite possible to adapt FDOS to other floppy disk interfaces, but it is not a task to be undertaken 
by a beginner or even an intermediate programmer. For those hardy souls who do attempt this task, this 
appendix is meant to provide helpful hints to ease the job. 


Other Hard-Sectored Interfaces 


The easiest disk interface to substitute is any form of interface which maintains the 77 tracks per disk, 
16 blocks per track, 278 bytes per block format. The user need only replace three routines for FDOS to 
use this type of interface, The three routines are INIT, GDWRT, and GDRED. Simply remove the code 
indicated in the FDOS listings as being the Floppy Drive I/O Routines (the section following MAPOT) and 
replace with the custom INIT, GDWRT, and GDRED routines, which function as follows: 


INIT causes all disk drives to return to track 0 and perform all necessary hardware and software ini- 
tialization for the interface to operate correctly. No registers need to be saved. INIT ends with 
a return (RET) instruction. 


GDWRT writes a 278 byte block of data onto the disk. The data resides in memory starting at loca- 
tion WRFLNM. The number of the disk drive to write to is stored at location WRDEV. The 
track and sector of the block to write the data to are stored in TRKWRT and TRKWRT+1, 
respectively. FDOS will attempt to write only even numbered disk sectors from 0 to 30 (deci- 
mal), because each data block is assumed to use two disk sectors. After writing the data, 
GDWRT should verify the written data. If the data was incorrect, a rewrite should be attempted. 
If GDWRT fails to write correctly after several attempts, GDWRT should return with the Z flag 
cleared (JNZ will branch). If the write was correct, then the Z flag is set. No registers have to be 
saved, 


GDRED reads a 278 byte block of data from the disk. The data read in is put into memory starting 
at RDFLNM. The number of the disk drive to read in from is found in memory byte DSKWNT. 
The track and sector numbers of the disk block to be read are found at TRKWNT and SECWNT, 
respectively. FDOS will only attempt to read even numbered sectors from 0 to 30 (decimal), 
because each disk block is assumed to take up two disk sectors. GDRED in conjunction with 
GDWRT should perform some sort of check sum verification that the data read in is correct. 
If data is not read in correctly, several attempts at rereading should be made. GDRED returns 
to FDOS with the Z flag cleared (JNZ will branch) if the data could not be read in properly. If 
the read was correct, then the Z flag is set. No registers need be preserved. 


If the user substitutes new INIT, GDWRT, and GDRED routines in FDOS, the version of PIP listed in 
this book will still operate properly, but the user must rewrite the programs SYSGEN, FORMAT, and 


BOOT to perform the functions required with the new interface hardware. 
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Different Numbers of Blocks or Tracks, 
Soft-Sectored Interfaces 


If the user maintains 278 byte disk blocks but the particular disk drive and interface combination does 
not use 77 tracks or 16 blocks per track, then in addition to the INIT, GDWRT, and GDRED changes, 
FDOS must be modified for the track or block changes. If a soft-sectored interface is used to store 278 
byte blocks, the user probably will not get 16 blocks on each track of an 8 inch disk, so this section also 
applies to most soft-sectored interfaces. 

The FDOS listing supplied includes conditional assembly directives for assembling this code for use on a 
5 inch floppy disk drive. This version of FDOS (mini-FDOS) changes both the number of tracks per disk 
and the number of blocks per track, which is exactly what the user referrring to this section wishes to do. 
To adapt FDOS to other numbers of blocks or tracks, then, the user should trace through the FDOS listing. 
Everywhere that there is either a MINI conditional assembly directive, or where the variables BLOCKS or 
TRACKS appear in the source code, modifications must be made to adapt FDOS to the different hardware. 
Changes will also have to be made in the PIP code in the DIRECTORY and FREE commands, 


Double Density 


The FDOS data structure lends itself readily to a double density hard-sectored interface, on either 
5 inch or full-sized floppy disk drives. FDOS currently uses only every other sector to store the disk blocks 
on. With double density recording, FDOS can store one data block on each sector. The programmer will 
have to make changes mainly in the NXTSCT and TS2BT routines. The bit map will have to be expanded to 
two blocks on the full-sized floppy disk interface, and so the MAPIN and MAPOT routines will also change. 
Major changes will be required by PIP and FORMAT to make use of the double density feature. 


Different Numbers of Bytes Per Block 


Changing the number of bytes in each disk block is probably the most involved of the changes described 
in this appendix. If a different number of bytes per block is used, then changes are needed in the BYTIN’ 
and BYTOT routines, which determine the number of bytes transferred in each BLKIN and BLKOT call. 
Minor changes will be required in BLKIN,; BLKOT, and DIRBLK. Additionally there will be many minor 
changes required that the user will only uncover by close examination of the source code or by trial and 
error with the user’s equipment. 

This appendix is not meant to discourage the many expert computer hobbyists who are quite capable 
of performing the conversion of FDOS to other formats. Rather, this appendix is an attempt to alert such 
users to the scope of the task and to provide some direction for those who choose to perform the modifica- 
sa The author would be delighted to hear from any persons successfully converting FDOS to other 

ardware, 


APPENDIX M: Interfacing to a 


5 Inch Floppy Disk Drive 


FDOS can be easily adapted to a 5 inch floppy disk drive. The FDOS source code listed in this book 
contains conditional assembly directives to allow the assembly of FDOS for use with a 5 inch floppy disk 
drive. The assembly directive variable is named MINI. In the assembly listing in Appendix H, MINI is 
equated to 0 at the start. This causes all of the code between the two lines 


IF MINI 
ENDIF 


to be ignored, and all of the code between the two lines 


IF NOT MINI 
ENDIF 


to be assembled. If the source code were reassembled with MINI equated to OFFFFH, the resulting code 
would run on a 5 inch floppy disk drive with the appropriate interface. Most of the differences in code are 
simple to hand patch if the user does not have the source code available. 


Software Differences 


The major difference between regular and mini-FDOS is the amount of storage area. Using hard-sectored 
disks with 16 sectors per track, mini-FDOS reads and writes 8 blocks of data per track. With only 35 or 40 
tracks to a disk, this reduces the total storage of data on one diskette to approximately 64 K with up to 112 
different files. Data transfer is also slower, and the time required for a head load operation increases drastic- 
ally because it includes the disk drive motor speed-up time. 


Hardware Differences 


The precise circuit required to use 5 inch floppy disk drives will not be detailed in this book, but it is 
nearly identical to the circuit in Appendix K. The major differences are that all input and output ports 
assigned to the interface are set 8 ports (numerically) lower than those in Appendix K, all clock frequencies 


are divided by 2, and a clock/data separator is added to the receive circuitry. 
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APPENDIX N: Program Chaining 


Pass 7 indicated that it is possible to chain multiple programs together such that the completion of one 
program causes another program to be loaded and run. This process is called chaining. 

FDOS accepts all of the RUN, JUMP, and SAVE commands from the console via the TXTIN routine. 
FDOS then uses the TI routine several times to interpret the command. If a program returns to FDOS via 
the RESTRT entry point, FDOS will attempt to interpret a command in the TXTIN buffer without first 
calling TXTIN to fill the buffer from the console. If the TXTIN buffer contains a valid command, FDOS 
will attempt to execute the command without any input from the user. By inserting a valid command in the 
TXTIN buffer before calling RESTRT, then, a program can cause another program to load and run. 

To perform chaining, the user must first understand the TXTIN buffer and how to access it. One of the 
User Accessible Addresses is called TXTPNT (see Appendix B). The listing of FDOS yields the construction 
as shown in Example N.1. 

A call to the TXTIN routines causes the edited string of ASCII entered from the console to be stored in 
the TXTIN buffer of 64 bytes starting at TXTBUF, and the address TXTBUF is stored in TXTPNT before 
TXTIN returns to the calling program. 

Each call to TI puts the byte pointed to by the address stored in TXTPNT into the accumulator and 
then increments the address stored in TXTPNT. 

To simulate a command entered via TXTIN, the user’s software must enter the ASCII command string 
in the TXTIN buffer at TXTBUF, and then reset the TXTPNT contents to point to the first byte of 
TXTBUF. 

Listing N.2 is an example of program chaining. In this instance EXMPL first sets the contents of 
TXTPNT equal to the address of TXTBUF (which is always TXTPNT+2), then proceeds to fill TXTBUF 
with a RUN BASIC<cr><If> command. When the command has been put into the buffer, EXMPL returns 
to FDOS via the RESTRT address. FDOS will now examine the TXTIN buffer and the RUN BASIC com- 
mand will be executed. 

The RUN command in PIP is an example of program chaining of a simple type, and the reader is invited 
to examine the listing of PIP in Appendix C to see how this is accomplished. Since the RUN command is 
already in the TXTIN buffer (because PIP uses TXTIN and TI to interpret the PIP commands) the only 
action required is to reset the TXTPNT contents to point to TXTBUF. This is done and PIP performs a 
RESTRT to cause the program chaining. 

One final note on program chaining: Whenever FDOS RUNs a program, the FILNAM routine is used to 
extract the file name to be run from the TXTIN buffer. After FDOS loads the program, the contents of the 
TXTIN buffer may not yet be exhausted. When the program to be run is entered from FDOS, the accumu- 
lator has the last character that was examined by the FILNAM routine, which is the character before that 
character which will be returned by the next call to TI. If the TXTIN buffer had contained the data: 


“RUN EDIT,TEXT:1 ASM&GO' 


j lator will contain 2CH 
then after the program EDIT was loaded, when FDOS jumps to EDIT the Accumu 
(ASCII for comma), and the TXTPNT pointer would point to the first T of TEXT:1. If the eset iar 
calls the FILNAM User Accessible Routine, then the file name TEXT:1 will be decoded into the file buffer 


area pointed to by the H and L registers. 
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This feature allows extra data to be sent with any FDOS RUN command, and this data can be entered 
either by the console device or by a program chaining command. It is quite possible to use this feature to 


allow a single typed command such as: 
‘RUN EDIT BLKJAK FORT NOLIST GO’ 


to first load and run an EDIT program. Here the EDIT program will edit the file BLKJAK, and after EDIT 
is finished it will chain in a FORTRAN compiler which will compile BLKJAK with no listing. When 
FORTRAN is finished, it in turn will chain in the compiled BLKJAK program and run it all from one 
command entered from the console. This example only scratches the surface of the actual possibilities and 
complexities available with program chaining under FDOS, but it should give the programmer a good start. 


ORG 0D030H 

DW TXTPNT 
TXTPNT: DW TXTBUF 
TXTBUF: DS 64 


Example N.1: See text for an explanation of this example. 


yw TxTert 
EXMPL: -EHLB-————OBO0830H _ ;HL gets the address of the pointer. 

MOV D,H ;DE gets a copy of HL 

MOV E,L 

INX D ;DE=DE+2, the first buffer location 

INX D 

MOV M,E ;store the TXTBUF address in TXTPNT 

INX H ;the first call to TI returns 

MOV M,D ;the byte at TXTBUF 

INX H ;HL now points to TXTBUF 

LXI D,CHAIN ;DE is data to fill buffer with 

MVI B,CHEND-CHAIN 311 bytes to transfer 
LOOP: LDAX D ;copy the data from CHAIN 

MOV M.A sinto TXTBUF 

INX H 

INX D 

DCR B 

JNZ LOOP ;until all bytes are moved 

JMP OD049H = ;go to RESTRT and RUN BASIC 
CHAIN: DB ‘RUN BASIC’ ,13,10 ;The command to chain 


CHEND: 


Example N.2: An example of program chaining, in which a 
program sets up another program to be executed aquto- 
matically following the end of the first program. 


—a86e60g0uBuEuECL———owmnmwmaoeo———eeooeoeoeeeeee———————— 
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APPENDIX O: 


Paper Tape Format of 


Source or Object Code 


For those users who require source or object code of any of the programs in this book on paper tape, write 
to the author at the address given below for information on the price and availability: 


Kenneth B. Welles 
2623 Fenwick Road 
University Heights, OH 44118 
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A Note About Bar Codes... 


Bar codes are the newest form of machine readable data rep- 
resentation. They are used in all PAPERBYTE™ software prod- 
ucts in BYTE magazine articles and self contained book publi- 
cations and combine efficiency of space, low cost, and ease of 
data entry with the need for mass produced machine readable 
representations of software. Bar codes were originally used for 
product identification in inventory control and supermarket 
checkout applications. Today, because of their direct binary 
representation of data, they are an ideal computer compatible 
communications medium. In the application of bar codes to soft- 
ware distribution (such as PAPERBYTE books and articles), 
the use of a simple but reliable optical scanning wand and an 
appropriate program provides a convenient means for the user 
to acquire software. 

Our intent in making PAPERBYTE software available in 
bar code formis to provide amethod of conveying machine read- 
able information from documentation to the memories and mass 
storage of a user's system ona one time basis. We suggest that 
the user of software obtained in this manner should locally record 
the data on the mass storage devices of his system after the data 
has been scanned from the printed page. The PAPERBYTE bar 
code representations provide a standardized means of obtaining 
the data, but they cannot be compared to the convenience 
oflocal mass storage devices suchas floppy disks, digital cassettes 
or audio cassettes. Thus if repeated use of the software obtained 
from bar code is anticipated, we recommend that the user make a 
copy on some form of magnetic medium. 

Bar Code Loader by Ken Budnik, the first in the PAPERBYTE 
series of software books, provides a brief history of bar codes, a 
look at the PAPERBYTE bar code format including flowcharts, a 
general bar code loader algorithm and well documented programs 
with complete implementation and checkout procedures for 
6800, 6502 and 8080/Z-80 based systems. 


